Tom Lane wrote:
>
> [EMAIL PROTECTED] writes:
> > \df causes an ERROR: Function oid8types(oidvector) does not exists
> > Thank everybody that can help me.
>
> Use the version of psql that matches your version of the server.
>
> This looks like a 6.5 or older psql with a 7.0 server...
Or a from
I am confirming this bug, though it appears that the order of creation is
not the issue. If you split the dump files into schema statements and copy
data statements and run them sequentially as two different jobs everything
works just fine.
The issue appears to be that create sequence (maybe cre
PL/pgSQL functions: NULL parameter trouble ([EMAIL PROTECTED]) reports a bug
with a severity of 1
The lower the number the more severe it is.
Short Description
Can not use NULL values at all
Long Description
If one of parameters is NULL, all another parameters
take NULL values regardless of tra
Could it also be the result of a Cluster operation? I've seen strange
things related to functions/triggers on tables that I've clustered.
>> At a guess, you've run into the known bug that foreign key triggers
>> don't track renames of referenced tables. Did you rename a table that
>> is a forei
PL/pgSQL functions:
if one of parameters is NULL, all another parameters
take NULL values regardless of transmitted NOT NULL values.
--
Vyacheslav Pryadkin
Software Engineer
SECTORBASE.com
568 Howard Str, First Floor
SF, CA, 94105
(415)365-8234
(415)760-0267 (cell)
Dear PGSQL-BUG group,
I would be grateful if any of you could provide me any information that you
may have.
I have written a perl program which runs fine on a machine that was using
PostgreSQL 6.4.2. I setup another machine which was running PostgreSQL
6.5.3 bundled by the Linux 6.2. I used th
I believe I have found a bug. I don't know whether the bug is with
PostgreSQL, MySQL, or the SQL specification. Please help me to
understand what I have. Thank you.
THE TEST SYSTEM
PostgreSQL version: 7.0.2
Platform: PentiumIII550x2, 512MB SDRAM, Linux2.2.13, glibc-2.1.2
[ken@ken ken]$ ldd /usr
On Fri, 27 Oct 2000, Jessica Ord wrote:
> I would be grateful if any of you could provide me any information that you
> may have.
>
> I have written a perl program which runs fine on a machine that was using
> PostgreSQL 6.4.2. I setup another machine which was running PostgreSQL
> 6.5.3 bundl
"Jessica Ord" <[EMAIL PROTECTED]> writes:
> I have written a perl program which runs fine on a machine that was using
> PostgreSQL 6.4.2. I setup another machine which was running PostgreSQL
> 6.5.3 bundled by the Linux 6.2.
> The same error message keeps on appear said that:
> Invalid use of ag
Ken Smith <[EMAIL PROTECTED]> writes:
> create table test (name char, a int, b int);
> insert into test values ('x', 1, 2);
> update test set a=3,b=a where name='x';
> select * from test;
> name | a | b
> --+---+---
> x| 3 | 1
This is correct ...
> I am used to MySQL so I expected the
> THE TEST
> Run 'psql', then enter the following except for the select statement
> output.
>
> ---BEGIN---
> create table test (name char, a int, b int);
> insert into test values ('x', 1, 2);
> select * from test;
> update test set a=3,b=a where name='x';
> insert into test values ('y', 1, 2);
At 15:28 27/10/00 +0900, Ken Smith wrote:
>
>Which behavior is the correct?
>
To quote from the stanard:
"Each is effectively evaluated for the current
row before any of the current row's object rows is updated"
So I'd say MySQL is wrong.
-
12 matches
Mail list logo
