database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-17 06:41:09 +03:00
Code Activity

Fix assertion failure when a SELECT DISTINCT ON expression is volatile.

Browse Source 
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.
This commit is contained in:
Tom Lane
2009-09-12 00:04:59 +00:00
parent 8c5463a511
commit d5a4b69c3a
4 changed files with 32 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
src/backend/optimizer/path/pathkeys.c
View File

@ -11,7 +11,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.98 2009/07/17 23:19:34 tgl Exp $
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.99 2009/09/12 00:04:59 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -635,6 +635,15 @@ convert_subquery_pathkeys(PlannerInfo *root, RelOptInfo *rel,
exprType((Node *) tle->expr),
exprTypmod((Node *) tle->expr),
0);
/*
* Note: it might look funny to be setting sortref = 0 for
* a reference to a volatile sub_eclass. However, the
* expression is *not* volatile in the outer query: it's
* just a Var referencing whatever the subquery emitted.
* (IOW, the outer query isn't going to re-execute the
* volatile expression itself.) So this is okay.
*/
outer_ec =
get_eclass_for_sort_expr(root,
outer_expr,