Hi.
I'm not sure if the following behaviour is expected or not.
Version info:
psql (PostgreSQL) 7.0.1
4.0-STABLE FreeBSD 4.0-STABLE #0: Tue Apr 25 18:34:52 EDT 2000
I have a table:
create table test (td timestamp);
I add a row:
insert into test values ('now');
I select from it casting td to a da
> "Michael Richards" <[EMAIL PROTECTED]> writes:
>> Shouldn't all casts be able to handle the case where it is NULL?
>
> Yup, it's a bug. It's fixed in current sources.
Is there a patch available that I can apply to the 7.0.2 source to
fix the p
Hi.
I believe this to be a bug, but I am submitting it to the SQL list as
well in the case I overlooked something.
I'm running
Postgres 7.0.2 on FreeBSD 4.0-STABLE/Intel
compiled with [gcc version 2.95.2 19991024 (release)]
I've got this interesting problem where the query plan is not what
Here is a bug and patch to fix it. I have tested this bug and fix on
FreeBSD/Intel and DecUX/Alpha machines. The bug appears in postgresql
6.5.3 and 7.0.2. Can someone please review it and apply it to the
source tree?
Sometimes when the postgres connection dies it is necessary to
attempt to r
Here are some log entries of the last dying words of postgres.
I've tried to reproduce this with limited success. Running this query
the first time caused the database to croak. I killed all the
processes in the STOP state ran ipcclean and restarted it. The server
seems to run the query fine af
Okay. I've narrowed it down just a little more.
If I start up postgres and run the query that caused it to crash
before, it will crash again iff it is the first query I run.
Even the slightest change in that query seems to stop it from
crashing. The original query was and should have returned:
I'm using postgres 7.0.2 on a FreeBSD 4.0-STABLE system. Compiled
with gcc version 2.95.2 19991024 (release).
When I create a table with a default timestamp of 'now' it works as
expected. When I create it with the timestamp 'now'::timestamp
explicitly specifying the type, it evaluates this to
I've got a test table in 7.0.3 where I'm implementing a directory
type structure in a RCS type system. I have a check to ensure that
there are no duplicate filenames within for a specific directory
given the revisionid of 0 (means it's the current revision rather
than a historical one).
CREAT
Hi.
I'm using 7.0.3 and I've found a bug:
create table test(value int4);
create function testfunc(int4)
RETURNS bool AS
'SELECT count(*)>0 AS RESULT FROM test where value= $1'
language 'SQL';
So I want this function to return true when it finds the specified
value in the t
I do not understand how this can possibly be correct unless NULL is
not permitted in a function.
In one case, I've got:
WHERE value= $1
Which is called with NULL and therefore should be:
WHERE value= NULL
This fails.
The other case which is logically equivalent I've got:
WHERE value= $1 OR ($1=
Hi.
I'm trying to compile 7.0.3 on a MIPS1 R3000 processor under NetBSD.
It pukes on the infamous s_lock.c file because of some assembler
that's expecting a MIPS2 processor.
gcc -I../../../include -I../../../backend -O2 -pipe -Wall -Wmissing-
prototypes -Wmissing-declarations -I../.. -c -
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
12 matches
Mail list logo
