mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-09-15 20:40:20 +02:00
d5a4b69c3a
In this case we generate two PathKey references to the expression (one for DISTINCT and one for ORDER BY) and they really need to refer to the same EquivalenceClass. However get_eclass_for_sort_expr was being overly paranoid and creating two different EC's. Correct behavior is to use the SortGroupRef index to decide whether two references to volatile expressions that are equal() (ie textually equivalent) should be considered the same. Backpatch to 8.4. Possibly this should be changed in 8.3 as well, but I'll refrain in the absence of evidence of a visible failure in that branch. Per bug #5049.
20 lines
584 B
SQL
20 lines
584 B
SQL
--
|
|
-- SELECT_DISTINCT_ON
|
|
--
|
|
|
|
SELECT DISTINCT ON (string4) string4, two, ten
|
|
FROM tmp
|
|
ORDER BY string4 using <, two using >, ten using <;
|
|
|
|
-- this will fail due to conflict of ordering requirements
|
|
SELECT DISTINCT ON (string4, ten) string4, two, ten
|
|
FROM tmp
|
|
ORDER BY string4 using <, two using <, ten using <;
|
|
|
|
SELECT DISTINCT ON (string4, ten) string4, ten, two
|
|
FROM tmp
|
|
ORDER BY string4 using <, ten using >, two using <;
|
|
|
|
-- bug #5049: early 8.4.x chokes on volatile DISTINCT ON clauses
|
|
select distinct on (1) floor(random()) as r, f1 from int4_tbl order by 1,2;
|