On Wed, Jan 14, 2015 at 07:29:24PM -0500, Tom Lane wrote:
> dst1 doesn't get an OID column:
>
> regression=# create table src1 (f1 int) with oids;
> CREATE TABLE
> regression=# create table dst1 (like src1);
> CREATE TABLE
> regression=# \d+ src1
> Table "public.src1"
> Column | Type | Modifiers | Storage | Stats target | Description
> --------+---------+-----------+---------+--------------+-------------
> f1 | integer | | plain | |
> Has OIDs: yes
>
> regression=# \d+ dst1
> Table "public.dst1"
> Column | Type | Modifiers | Storage | Stats target | Description
> --------+---------+-----------+---------+--------------+-------------
> f1 | integer | | plain | |
>
>
> If you don't find that problematic, how about this case?
>
> regression=# create table src2 (f1 int, primary key(oid)) with oids;
> CREATE TABLE
> regression=# create table dst2 (like src2 including indexes);
> ERROR: column "oid" named in key does not exist
I have developed the attached patch to fix this. The code was basically
confused because setting cxt.hasoids had no effect, and the LIKE
relation was never checked.
The fix is to default cxt.hasoids to false, set it to true if the LIKE
relation has oids, and add WITH OIDS to the CREATE TABLE statement, if
necessary. It also honors WITH/WITHOUT OIDS specified literally in the
CREATE TABLE clause because the first specification is honored, and we
only append WITH OIDS if the LIKE table has oids.
Should this be listed in the release notes as a backward-incompatibility?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
