From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Lenski <dlenski(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Why can't I select un-grouped columns when grouping by a (non-primary) unique key? |
Date: | 2014-09-24 18:19:10 |
Message-ID: | 22599.1411582750@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Daniel Lenski <dlenski(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Bandy | 2014-09-24 19:02:00 | Re: Custom type literal conversion |
Previous Message | Daniel Lenski | 2014-09-24 18:17:20 | Re: Why can't I select un-grouped columns when grouping by a (non-primary) unique key? |