Re: Why can't I select un-grouped columns when grouping by a (non-primary) unique key?

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

In response to

Browse pgsql-general by date

  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?