Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?
От | Tom Lane |
---|---|
Тема | Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property? |
Дата | |
Msg-id | 10622.1430000125@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Shouldn't CREATE TABLE LIKE copy the relhasoids
property?
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > No, I just misread your email. I thought you said you had attached > the patch; rereading it, I see that you said you had applied the > patch. Silly me. The real problem with this patch is it's wrong. Specifically, it broke the other case I mentioned in my original email: regression=# create table src2 (f1 int, primary key(oid)) with oids; ERROR: column "oid" named in key does not exist LINE 1: create table src2 (f1 int, primary key(oid)) with oids; ^ That works in 9.4, and was still working in HEAD as of my original email. I think the patch's logic for attaching made-up OIDS options is actually backwards (it's adding TRUE where it should add FALSE and vice versa), but in any case I do not like the dependence on default_with_oids that was introduced by the patch. I am not sure there's any guarantee that default_with_oids can't change between parsing and execution of a CREATE TABLE command. Apparently we need a few more regression tests in this area. In the meantime I suggest reverting and rethinking the patch. regards, tom lane
В списке pgsql-hackers по дате отправления: