Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL
| От | Tom Lane |
|---|---|
| Тема | Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" in child table must be marked NOT NULL |
| Дата | |
| Msg-id | 25058.1501077775@sss.pgh.pa.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL (Michael Paquier <michael.paquier@gmail.com>) |
| Ответы |
Re: [HACKERS] pg_upgrade failed with error - ERROR: column "a" inchild table must be marked NOT NULL
|
| Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > 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? Yeah, I think we really ought to for consistency. Quite aside from pg_dump hazards, this allows situations where selecting from an apparently not-null column can produce nulls (coming from unconstrained child tables). That's exactly what the automatic inheritance rules are intended to prevent. If we had a way to mark NOT NULL constraints as not-inherited, it'd be legitimate for ADD PRIMARY KEY to paste on one of those instead of a regular one ... but we lack that feature, so it's moot. Not sure what's involved there code-wise, though, nor whether we'd want to back-patch. regards, tom lane
В списке pgsql-hackers по дате отправления: