On Thu, Mar 22, 2018 at 5:20 PM, David Rowley <david.row...@2ndquadrant.com> wrote:
> The problem is that in order to properly invalidate cached plans we > must record the constraint OIDs which the plan depends on. We can do > that for PK and UNIQUE constraints, unfortunately, we can't do it for > NOT NULL constraints as, at the moment, these are just properties of > pg_attribute. For this to be made to work we'd need to store those in > pg_constraint too, which is more work that I'm going to do for this > patch. > I was just wondering, since get_primary_key_attnos opens pg_constraint and just skips attributes with other constraint types than primary, what would be the reason we wouldn't just also open pg_attribute and check for the non-nullness of the non-primary key unique attributes? Couldn't we add a function which opens both pg_attribute and pg_constraint to get non-null unique attributes? I suppose that would have a performance impact. And, I did notice the FIXME in the comment before check_functional_grouping which seems to make the argument that there are other use cases for wanting the non-nullness represented in pg_constraint. * Currently we only check to see if the rel has a primary key that is a * subset of the grouping_columns. We could also use plain unique constraints * if all their columns are known not null, but there's a problem: we need * to be able to represent the not-null-ness as part of the constraints added * to *constraintDeps. FIXME whenever not-null constraints get represented * in pg_constraint. */ -- Melanie Plageman