Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?
От | Bruce Momjian |
---|---|
Тема | Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property? |
Дата | |
Msg-id | 20150426020045.GF17791@momjian.us обсуждение исходный текст |
Ответ на | Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?
|
Список | pgsql-hackers |
On Sat, Apr 25, 2015 at 06:15:25PM -0400, Tom Lane wrote: > 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; > ^ Wow, thanks for seeing that mistake. I had things just fine, but then I decided to optimize it and forgot that this code is used in non-LIKE situations. Reverted. > 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. I have changed the default value back to the function call as it should have been all along; patch attached. I will revisit this for 9.6 unless I hear otherwise. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
Вложения
В списке pgsql-hackers по дате отправления: