On Wed, Jun 15, 2016 at 10:34 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.com> writes: > This doesn't sound like the right approach; in particular, it won't really > help for deciding whether to propagate a DROP NOT NULL on a parent rel to > its children. What we've discussed in the past is to store NOT NULL > constraints in pg_constraint, much like CHECK constraints are already, and > use use-count logic identical to the CHECK case to keep track of whether > NOT NULL constraints are inherited or not. My feeling is that we'd keep > the pg_attribute.attnotnull field and continue to drive actual enforcement > off that, but it would just reflect a summary of the pg_constraint state.
OK, I see. Hm, by storing this information I would actually think that we want to drop this attnotnull so as we don't need to bother about updating pg_attribute through the whole tree when dropping a NOT NULL constraint on the parent, and we do not actually need to store this information in two different places.. I would also rather do nothing for the DDL interface regarding for example the possibility to change the constraint names for domains and tables to keep things simple. A patch of this caliber would be complicated enough if a catalog switch is done. > IIRC, Alvaro posted a WIP patch for that awhile back. Not sure what the > current state is. Are you talking about that? https://www.postgresql.org/message-id/20110707213401.GA27098%40alvh.no-ip.org This is not a small patch :) Alvaro, others, any opinions? -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers