Postgres-7.0.3-2
RedHat-6.2
SELECT int8(5*27.81*100);
13904
SELECT int4(5*27.81*100);
13905
SELECT int8(27.81*100*5);
13905
--
ó Õ×ÁÖÅÎÉÅÍ, ÷ÁÝÅÎËÏ íÁËÓÉÍ,
îÉÖÅÇÏÒÏÄÓËÉÅ ÉÎÆÏÒÍÁÃÉÏÎÎÙÅ ÓÅÔÉ
(8312) 30-19-05, 34-00-02, 30-09-73
With best regards, Max Vaschenko,
Nizhny Novgoro
Alexander Dietrich ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
JDBC driver throws SQLException while parsing timestamp
Long Description
Hi,
there's a discrepancy between PreparedStatement.setTimestamp() and
ResultSet.getTi
([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
large objects overwriting bug
Long Description
When overwriting an lo with a larger lo, the old data is not overwritten. This was
supposed to be fixed in 6.5, but it happens in
This problem is not specific to Postgres. If you play around with a little C
program like:
#include
int main(int argc, char * argv[])
{
float f = 27.81;
int i = 5;
int l = 100;
int ii = i*f*l;
long ll = l*f*i;
float ff = i*f*l;
print
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
>
> Is this a bug? Can someone submit a patch?
Why not setBoolean(parameterIndex,((Boolean)x),booleanValue());
Also, unless it's changed postgres accepts 't' & 'f' not 'true' or 'false'?
Also, which PreparedStatement.java are we taking about, as the
Quoting Bruce Momjian <[EMAIL PROTECTED]>:
>
> Anyone fixing this bug?
>
> > I reported a JDBC bug in the 7.1 beta1 release back in December and
> notice that the same bug is still present in the current beta 3 sources.
> The problem relates to nested cursors failing and is quite simple to
> r
Quoting [EMAIL PROTECTED]:
> Paul M. Aoki ([EMAIL PROTECTED]) reports a bug with a severity of 3
> The lower the number the more severe it is.
>
> Short Description
> no way in LargeObject API to detect short read?
Will check to see how libpq (which this API is based on) handles this. I've got
POSTGRESQL BUG REPORT TEMPLATE
Your name : Gonzalo Arana
Your email address : [EMAIL PROTECTED]
System Con
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Anyone able to fix this?
here's a hack we've been using in-house (written by Jun Gabayan,
<[EMAIL PROTECTED]>).
you may not like the style but it's a stab at a solution.
--
Paul M. Aoki / Xerox Palo Alto Research Center / Coyote Hill Road
[EMAIL
Hi,
First off I'm running:
links=# select version() ;
version
-
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
Now, if I have a table w
On Wed, Jan 24, 2001 at 05:50:24PM -0300,
Gonzalo Arana <[EMAIL PROTECTED]> wrote:
>
> It seems that there is a problem when retrieving a timestamp value (rounding).
>
> NO minute has 61 seconds. Am I wrong?
When leap seconds occur, minutes can have 61 seconds.
Darcy ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
pl/pgsql documentation
Long Description
The following documentation does not apear to reflect real world use.
[<>]
FOR record | row IN select_clause LOOP
statements
END
> radius=# create table x (x timestamp);
> CREATE
> radius=# insert into x (x) values ('Tue 23 Jan 21:38:59.997 2001');
> INSERT 619178 1
> radius=# select * from x;
> x
> -
> Tue 23 Jan 21:38:60.00 2001 ART
> (1 row)
>
> radius=#
Ok this has since been sorted out, however I propose that it is better
layed out in the documentation, or at the veryleast an example is given.
i MUST be defined as a RECORD, and you then refrence the returned result as
RECORD.field, Also you can NOT have ()'s arouns the select statement.
CREATE
[EMAIL PROTECTED] writes:
> When overwriting an lo with a larger lo, the old data is not overwritten. This was
>supposed to be fixed in 6.5, but it happens in 7.0.3.
Please try your test case in 7.1beta3 or later. The large-object
support has been rather completely rewritten ... if this bug is
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> This problem is not specific to Postgres.
The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety
floating-point roundoff error. However, I think Max has a fair
complaint here: it seems float-to-int8 conversion is truncating, not
ro
Alex Krohn <[EMAIL PROTECTED]> writes:
> links=# select * from foo where a like 'Test/%'
> links-# ;
> a
> ---
> (0 rows)
This looks like an artifact of the known problems with LIKE index
optimization in non-ASCII locales. What locale are you running the
On Thursday 25 January 2001 22:52, Tom Lane wrote:
> "Robert B. Easter" <[EMAIL PROTECTED]> writes:
> > This problem is not specific to Postgres.
>
> The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety
> floating-point roundoff error. However, I think Max has a fair
> complaint
Is postgres going to use the scientific method of rounding or just
the simple one? Or even make it configurable. As I recall, the
scientific method says that 4.5 should be rounded to 4 and 5.5 should
be rounded to 6. The idea was that even numbers were easier to work
with and rounding all the
19 matches
Mail list logo
