as methods for implementing the DISTINCT step. This eliminates the former
performance gap between DISTINCT and GROUP BY, and also makes it possible
to do SELECT DISTINCT on datatypes that only support hashing not sorting.
SELECT DISTINCT ON is still always implemented by sorting; it would take
executor changes to support hashing that, and it's not clear it's worth
the trouble.
This is a release-note-worthy incompatibility from previous PG versions,
since SELECT DISTINCT can no longer be counted on to deliver sorted output
without explicitly saying ORDER BY. (Anyone who can't cope with that
can consider turning off enable_hashagg.)
Several regression test queries needed to have ORDER BY added to preserve
stable output order. I fixed the ones that manifested here, but there
might be some other cases that show up on other platforms.
after trying to resolve the item as an input-column name. This allows us
to be compliant with the SQL92 spec for queries that fall within the spec,
while still accepting the same out-of-spec queries as 6.5 did. You'll only
lose if there is an output column name that is the same as an input
column name, but doesn't refer to the same value. 7.0 will interpret
such a GROUP BY spec differently than 6.5 did. No way around that, because
6.5 was clearly not spec compliant.
interpret a column name as an output column alias (targetlist AS name),
ather than a real column name as it ought to. According to the spec,
only ORDER BY should look at output column names. I left in GROUP BY's
willingness to use an output column number ('GROUP BY 2'), even though
this is also contrary to the spec --- again, only ORDER BY is supposed
to accept that. But there is no possible reason to want to GROUP BY
an integer constant, so keeping this old behavior won't break any
SQL-compliant queries. DISTINCT ON will behave the same as GROUP BY.
Change numerology regress test, which depended on the incorrect
behavior.
Peter Eisentraut
Tom Lane
Thomas G. Lockhart