Greg Stark <gsst...@mit.edu> writes:
> The first step is probably to do the opposite of what we're talking
> about here: cases where people *have* added extra columns to the GROUP
> BY key so they can use those columns in their select list. We can
> remove those columns from the sort or hash comparison key if there's a
> column (or columns) which is a unique constraint key for the same
> source. Similarly we can remove columns from an ORDER BY if the order
> key has earlier columns which are already a unique key for the same
> source.
This is something we could only do at plan time --- if we do it at parse
time we risk making a robust query into one that will break when
somebody drops a constraint. So it's not really the inverse of the
other case.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
