Daniel Lenski <dlenski@xxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
