The following bug has been logged online:
Bug reference: 1608
Logged by: Paul
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.2
Operating system: Gentoo and Fedora Core 3
Description:integer negative limit in plpgsql function arguments
Details:
The script b
It is Sawai.
(B
(BI am sorry. There is a correction.
(B
(B>The following server logs are output when the program that gets a large
(B>amount of Connection with PostgreSQL8.0.1/8.0.2 is operated, and PostgreSQL
(B>stops. Concretely, all the postgres processes and the postmaster processes
(
"Paul" <[EMAIL PROTECTED]> writes:
> -- this doesn't work (and I think it should!)
> SELECT print_test_id(-2147483648);
"2147483648" isn't an integer constant; it's int8, and therefore so
is the result of the minus operator. Sorry, this isn't going to
change.
regards, tom
The following bug has been logged online:
Bug reference: 1609
Logged by: Oliver Siegmar
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.2
Operating system: Linux
Description:Bug in interval datatype for 64 Bit timestamps
Details:
Postgres compiled with --en
"Oliver Siegmar" <[EMAIL PROTECTED]> writes:
> select '10.10 secs ago'::interval;
> interval
> ---
> @ 10.-10 secs ago
> (1 row)
What datestyle are you using?
regards, tom lane
---(end of broadcast)---
Oliver Siegmar <[EMAIL PROTECTED]> writes:
>> What datestyle are you using?
> Non-ISO (Postgres in that case), but the handling for non-ISO is all the same
> in interval.c ...
Yeah, I just confirmed here that it's broken the same way in all three
non-ISO datestyles. Will look into a fix later to
I've applied this patch.
regards, tom lane
Index: datetime.c
===
RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.137
diff -c -r1.137 datetime.c
*** datetime.c 11 Jan 2005 18:
Hi Tom,
On Wednesday 20 April 2005 17:57, Tom Lane wrote:
> "Oliver Siegmar" <[EMAIL PROTECTED]> writes:
> > select '10.10 secs ago'::interval;
> >
> > interval
> > ---
> > @ 10.-10 secs ago
> > (1 row)
>
> What datestyle are you using?
Non-ISO (Postgres in that case), but t
Paul Edwards <[EMAIL PROTECTED]> writes:
> Also, just as an experiment I tried the minimum limit for bigint (see
> attached file). It seems that I do not need to cast for negative limit
> which is inconsistent since 9223372036854775808 is not a bigint (when
> -9223372036854775808 is). Therefore t
