mirror of
https://github.com/postgres/postgres.git
synced 2025-04-24 10:47:04 +03:00
The result of a FULL or RIGHT join can't be assumed to be sorted by the
left input's sorting, because null rows may be inserted at various points. Per report from Ferenc Lutischá¸n.
This commit is contained in:
parent
d08889aa8b
commit
94e4778a31
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.91 2004/12/31 22:00:04 pgsql Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.92 2005/01/23 02:21:26 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -271,7 +271,8 @@ sort_inner_and_outer(Query *root,
|
||||
cur_mergeclauses,
|
||||
innerrel);
|
||||
/* Build pathkeys representing output sort order. */
|
||||
merge_pathkeys = build_join_pathkeys(root, joinrel, outerkeys);
|
||||
merge_pathkeys = build_join_pathkeys(root, joinrel, jointype,
|
||||
outerkeys);
|
||||
|
||||
/*
|
||||
* And now we can make the path.
|
||||
@ -431,7 +432,7 @@ match_unsorted_outer(Query *root,
|
||||
* as a nestloop, and even if some of the mergeclauses are
|
||||
* implemented by qpquals rather than as true mergeclauses):
|
||||
*/
|
||||
merge_pathkeys = build_join_pathkeys(root, joinrel,
|
||||
merge_pathkeys = build_join_pathkeys(root, joinrel, jointype,
|
||||
outerpath->pathkeys);
|
||||
|
||||
if (nestjoinOK)
|
||||
|
@ -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.63 2004/12/31 22:00:04 pgsql Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.64 2005/01/23 02:21:26 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -858,7 +858,12 @@ build_subquery_pathkeys(Query *root, RelOptInfo *rel, Query *subquery)
|
||||
* vars they were joined with; furthermore, it doesn't matter what kind
|
||||
* of join algorithm is actually used.
|
||||
*
|
||||
* EXCEPTION: in a FULL or RIGHT join, we cannot treat the result as
|
||||
* having the outer path's path keys, because null lefthand rows may be
|
||||
* inserted at random points. It must be treated as unsorted.
|
||||
*
|
||||
* 'joinrel' is the join relation that paths are being formed for
|
||||
* 'jointype' is the join type (inner, left, full, etc)
|
||||
* 'outer_pathkeys' is the list of the current outer path's path keys
|
||||
*
|
||||
* Returns the list of new path keys.
|
||||
@ -866,8 +871,12 @@ build_subquery_pathkeys(Query *root, RelOptInfo *rel, Query *subquery)
|
||||
List *
|
||||
build_join_pathkeys(Query *root,
|
||||
RelOptInfo *joinrel,
|
||||
JoinType jointype,
|
||||
List *outer_pathkeys)
|
||||
{
|
||||
if (jointype == JOIN_FULL || jointype == JOIN_RIGHT)
|
||||
return NIL;
|
||||
|
||||
/*
|
||||
* This used to be quite a complex bit of code, but now that all
|
||||
* pathkey sublists start out life canonicalized, we don't have to do
|
||||
|
@ -8,7 +8,7 @@
|
||||
* Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* $PostgreSQL: pgsql/src/include/optimizer/paths.h,v 1.77 2004/12/31 22:03:36 pgsql Exp $
|
||||
* $PostgreSQL: pgsql/src/include/optimizer/paths.h,v 1.78 2005/01/23 02:21:36 tgl Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -114,6 +114,7 @@ extern List *build_subquery_pathkeys(Query *root, RelOptInfo *rel,
|
||||
Query *subquery);
|
||||
extern List *build_join_pathkeys(Query *root,
|
||||
RelOptInfo *joinrel,
|
||||
JoinType jointype,
|
||||
List *outer_pathkeys);
|
||||
extern List *make_pathkeys_for_sortclauses(List *sortclauses,
|
||||
List *tlist);
|
||||
|
Loading…
x
Reference in New Issue
Block a user