Re: Shouldn't CREATE TABLE LIKE copy the relhasoids property?

On Sat, Apr 25, 2015 at 11:11:52PM -0400, Tom Lane wrote:
> Hm, good point; INHERITS will silently override such a specification:
>
> regression=# create table base1 (f1 int) with oids;
> CREATE TABLE
> regression=# create table c2 () inherits (base1) without oids;
> CREATE TABLE
> regression=# \d+ c2
>                           Table "public.c2"
>  Column |  Type   | Modifiers | Storage | Stats target | Description
> --------+---------+-----------+---------+--------------+-------------
>  f1     | integer |           | plain   |              |
> Inherits: base1
> Has OIDs: yes
>
> > Though I guess unlike inherits there is no
> > reason to mandate the final result be identical to the base table - though
> > here is something to be said for pointing out the inconsistency and
> > requiring the user to alter table if indeed they want to have the oid-ness
> > changed.
>
> Yeah, LIKE doesn't necessarily have to behave the same as INHERITS;
> but probably we should follow that precedent unless we have a specific
> argument not to.  Which I don't.

Agreed.  Here is an attached patch for 9.6 which works for multiple
LIKE'ed tables with multiple inheritance and index creation.  I figured
out why Tom's OID primary key test was failing so I now process the
columns and LIKE first, then the constraints.  There is also no longer a
dependency on default_with_oids.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +