From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)hub(dot)org |
Subject: | Re: [HACKERS] pg_dump problem? |
Date: | 1999-05-07 21:16:58 |
Message-ID: | 17400.926111818@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> "D'Arcy" "J.M." Cain <darcy(at)druid(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-05-07 22:14:47 | NUMERIC type conversions leave much to be desired |
Previous Message | Tom Lane | 1999-05-07 18:08:03 | Re: [HACKERS] Re: Nasty resource-leak problem in sort code |