mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-15 08:20:16 +08:00
Code Issues Packages Projects Releases Wiki Activity

The result of a FULL or RIGHT join can't be assumed to be sorted by the

Browse Source 
left input's sorting, because null rows may be inserted at various points.
Per report from Ferenc Lutischá¸n.
This commit is contained in:
Tom Lane 2005-01-23 02:26:05 +00:00
parent 2b47146a07
commit 66bb44cf63
3 changed files with 16 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
src/backend/optimizer/path/joinpath.c
View File

@ -8,7 +8,7 @@
*
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/joinpath.c,v 1.67 2001/11/11 19:18:54 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/joinpath.c,v 1.67.2.1 2005/01/23 02:25:25 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -253,7 +253,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. We only consider the cheapest-
@ -371,7 +372,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
src/backend/optimizer/path/pathkeys.c
View File

@ -11,7 +11,7 @@
* Portions Copyright (c) 1994, Regents of the University of California
*
* IDENTIFICATION
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.36 2001/11/11 20:33:53 tgl Exp $
* $Header: /cvsroot/pgsql/src/backend/optimizer/path/pathkeys.c,v 1.36.2.1 2005/01/23 02:25:30 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -621,7 +621,12 @@ find_indexkey_var(Query *root, RelOptInfo *rel, AttrNumber varattno)
* 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.
@ -629,8 +634,12 @@ find_indexkey_var(Query *root, RelOptInfo *rel, AttrNumber varattno)
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

3
src/include/optimizer/paths.h
View File

@ -8,7 +8,7 @@
* Portions Copyright (c) 1996-2001, PostgreSQL Global Development Group
* Portions Copyright (c) 1994, Regents of the University of California
*
* $Id: paths.h,v 1.59 2001/11/05 17:46:34 momjian Exp $
* $Id: paths.h,v 1.59.2.1 2005/01/23 02:26:05 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@ -112,6 +112,7 @@ extern List *build_index_pathkeys(Query *root, RelOptInfo *rel,
ScanDirection scandir);
extern List *build_join_pathkeys(Query *root,
RelOptInfo *joinrel,
JoinType jointype,
List *outer_pathkeys);
extern List *make_pathkeys_for_sortclauses(List *sortclauses,
List *tlist);