Tom Lane-2 wrote
> Ah. This is not pg_dump's fault, because actually what you've got here
> is a logically inconsistent database: at this point, it's possible to
> select from a00 and see some rows with null name values, which should
> not be possible given the declared NOT NULL constraint on a00.name.
>
> This is a known limitation of the backend. It should refuse to let you
> DROP NOT NULL in a case where the NOT NULL is an inherited constraint,
> as it is here. It would not let you drop a CHECK constraint in an
> equivalent situation; but the NOT NULL support is older/more primitive
> and currently doesn't do enough bookkeeping to realize that a03's NOT NULL
> constraint is inherited from a parent table. Fixing that is on our to-do
> list, but it hasn't been very high priority.
>
> regards, tom lane
Thank you for your explanations, I have already made changes to my model.
--
View this message in context: http://postgresql.nabble.com/pg-dump-wrong-order-with-inheritance-tp5874794p5874935.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
