Re: [HACKERS] pg_dump problem? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] pg_dump problem?
Date
Msg-id 17400.926111818@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] pg_dump problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
I wrote:
> "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
>> I do know that the following crashed the backend.
>> darcy=> insert into x (oid, n) values (1234567, 123.456);

> This is definitely a bug --- it should either do it or give an
> error message...

Actually, with recent sources you get:

regression=> insert into x (oid, n) values (1234567, 123.456);
ERROR:  Cannot assign to system attribute 'oid'

I had put in a patch to defend against "UPDATE table SET oid = ...",
and it evidently catches the INSERT case too.

I am not sure how much work it would take to actually accept an INSERT/
UPDATE that sets the OID field.  There is a coredump in the parser if
you take out the above check; it wouldn't be hard to fix that coredump
but I haven't looked to see what else may lurk beyond it.
(preprocess_targetlist is a danger zone that comes to mind.)

Anyway, this definitely looks like a "new feature" that is not going to
get done for 6.5.  Perhaps someone will get interested in making it work
for 6.6 or later.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Re: Nasty resource-leak problem in sort code
Next
From: Tom Lane
Date:
Subject: NUMERIC type conversions leave much to be desired