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. +
