Re: [HACKERS] pg_dump problem?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_dump problem? |
Дата | |
Msg-id | 17400.926111818@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_dump problem? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: