Bruce Momjian <br...@momjian.us> writes:
> 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.
I still don't like this patch one bit. I don't think that this code
should be modifying stmt->options that way. Also, you have not addressed
whether this is even the right semantics. In particular, currently
default_with_oids will force an OID column to exist regardless of whether
the LIKE-referenced table has them:
regression=# create table base (f1 int);
CREATE TABLE
regression=# set default_with_oids = true;
SET
regression=# create table likeit (like base);
CREATE TABLE
regression=# \d+ base
Table "public.base"
Column | Type | Modifiers | Storage | Stats target | Description
--------+---------+-----------+---------+--------------+-------------
f1 | integer | | plain | |
regression=# \d+ likeit
Table "public.likeit"
Column | Type | Modifiers | Storage | Stats target | Description
--------+---------+-----------+---------+--------------+-------------
f1 | integer | | plain | |
Has OIDs: yes
Another variant is "create table likeit (like base) with oids".
It's perhaps debatable whether it should act that way, but in the absence
of complaints from the field, I'm hesitant to change these cases. It
might be better if the effective behavior were "table gets OIDs if
default_with_oids = true or WITH OIDS is given or base table has OIDs".
Still another case that needs to be thought about is "create table likeit
(like base) without oids" where base does have OIDs. Probably the right
thing here is to let the WITHOUT OIDS spec override what we see in base.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
