On Wed, Jul 26, 2017 at 12:09 PM, tushar <tushar.ah...@enterprisedb.com> wrote: > v9.5/9.6 > > create these objects - > CREATE TABLE constraint_rename_test (a int CONSTRAINT con1 CHECK (a > 0), b > int, c int); > CREATE TABLE constraint_rename_test2 (a int CONSTRAINT con1 CHECK (a > 0), d > int) INHERITS (constraint_rename_test); > ALTER TABLE constraint_rename_test ADD CONSTRAINT con3 PRIMARY KEY (a); > > v9.6/v10 - run pg_upgrade > > pg_restore: creating COMMENT "SCHEMA "public"" > pg_restore: creating TABLE "public.constraint_rename_test" > pg_restore: creating TABLE "public.constraint_rename_test2" > pg_restore: [archiver (db)] Error while PROCESSING TOC: > pg_restore: [archiver (db)] Error from TOC entry 351; 1259 16388 TABLE > constraint_rename_test2 edb > pg_restore: [archiver (db)] could not execute query: ERROR: column "a" in > child table must be marked NOT NULL > Command was: > -- For binary upgrade, must preserve pg_type oid > SELECT > pg_catalog.binary_upgrade_set_next_pg_type_oid('16390'::pg_catalog.oid); > > manually i am able to create all these objects .
You can go further down to reproduce the failure of your test case. I can see the same thing with at least 9.3, which is as far as I tested, for any upgrade combinations up to HEAD. And I would imagine that this is an old behavior. The documentation says the following: https://www.postgresql.org/docs/9.3/static/ddl-inherit.html All check constraints and not-null constraints on a parent table are automatically inherited by its children. Other types of constraints (unique, primary key, and foreign key constraints) are not inherited. When adding a primary key, the system does first SET NOT NULL on each column under cover, but this does not get spread to the child tables as this is a PRIMARY KEY. The question is, do we want to spread the NOT NULL constraint created by the PRIMARY KEY command to the child tables, or not? It is easy enough to fix your problem by switching the second and third commands in your test case, still I think that the current behavior is non-intuitive, and that we ought to fix this by applying NOT NULL to the child's columns when a primary key is added to the parent. Thoughts? -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers