Daniel Lenski <dlenski@gmail.com> writes:
> Now that I understand PG's current behavior, it doesn't seem like a
> huge limitation... but I'm curious about what is preventing the UNIQUE
> NOT NULL constraints from being allowed as well. Is there something
> different about the internal representation of UNIQUE NOT NULL
> constraints compared to PRIMARY KEY constraints?
The comments for check_functional_grouping() explain where the holdup is:
* Determine whether a relation can be proven functionally dependent on
* a set of grouping columns. If so, return TRUE and add the pg_constraint
* OIDs of the constraints needed for the proof to the *constraintDeps list.
*
* grouping_columns is a list of grouping expressions, in which columns of
* the rel of interest are Vars with the indicated varno/varlevelsup.
*
* 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.
regards, tom lane
