mirror of
https://github.com/postgres/postgres.git
synced 2025-07-27 12:41:57 +03:00
Re-run pgindent, fixing a problem where comment lines after a blank
comment line where output as too long, and update typedefs for /lib directory. Also fix case where identifiers were used as variable names in the backend, but as typedefs in ecpg (favor the backend for indenting). Backpatch to 8.1.X.
This commit is contained in:
Bruce Momjian
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.137 2005/10/15 02:49:19 momjian Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/allpaths.c,v 1.138 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -440,8 +440,8 @@ set_subquery_pathlist(PlannerInfo *root, RelOptInfo *rel,
|
||||
* Restrictions on individual clauses are checked by
|
||||
* qual_is_pushdown_safe().
|
||||
*
|
||||
* Non-pushed-down clauses will get evaluated as qpquals of the SubqueryScan
|
||||
* node.
|
||||
* Non-pushed-down clauses will get evaluated as qpquals of the
|
||||
* SubqueryScan node.
|
||||
*
|
||||
* XXX Are there any cases where we want to make a policy decision not to
|
||||
* push down a pushable qual, because it'd result in a worse plan?
|
||||
|
||||
@ -49,7 +49,7 @@
|
||||
* Portions Copyright (c) 1994, Regents of the University of California
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.149 2005/10/15 02:49:19 momjian Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/costsize.c,v 1.150 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -155,8 +155,8 @@ cost_seqscan(Path *path, PlannerInfo *root,
|
||||
/*
|
||||
* disk costs
|
||||
*
|
||||
* The cost of reading a page sequentially is 1.0, by definition. Note that
|
||||
* the Unix kernel will typically do some amount of read-ahead
|
||||
* The cost of reading a page sequentially is 1.0, by definition. Note
|
||||
* that the Unix kernel will typically do some amount of read-ahead
|
||||
* optimization, so that this cost is less than the true cost of reading a
|
||||
* page from disk. We ignore that issue here, but must take it into
|
||||
* account when estimating the cost of non-sequential accesses!
|
||||
@ -480,8 +480,8 @@ cost_bitmap_heap_scan(Path *path, PlannerInfo *root, RelOptInfo *baserel,
|
||||
/*
|
||||
* Estimate CPU costs per tuple.
|
||||
*
|
||||
* Often the indexquals don't need to be rechecked at each tuple ... but not
|
||||
* always, especially not if there are enough tuples involved that the
|
||||
* Often the indexquals don't need to be rechecked at each tuple ... but
|
||||
* not always, especially not if there are enough tuples involved that the
|
||||
* bitmaps become lossy. For the moment, just assume they will be
|
||||
* rechecked always.
|
||||
*/
|
||||
@ -869,13 +869,14 @@ cost_agg(Path *path, PlannerInfo *root,
|
||||
* We will produce a single output tuple if not grouping, and a tuple per
|
||||
* group otherwise. We charge cpu_tuple_cost for each output tuple.
|
||||
*
|
||||
* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the same
|
||||
* total CPU cost, but AGG_SORTED has lower startup cost. If the input
|
||||
* path is already sorted appropriately, AGG_SORTED should be preferred
|
||||
* (since it has no risk of memory overflow). This will happen as long as
|
||||
* the computed total costs are indeed exactly equal --- but if there's
|
||||
* roundoff error we might do the wrong thing. So be sure that the
|
||||
* computations below form the same intermediate values in the same order.
|
||||
* Note: in this cost model, AGG_SORTED and AGG_HASHED have exactly the
|
||||
* same total CPU cost, but AGG_SORTED has lower startup cost. If the
|
||||
* input path is already sorted appropriately, AGG_SORTED should be
|
||||
* preferred (since it has no risk of memory overflow). This will happen
|
||||
* as long as the computed total costs are indeed exactly equal --- but if
|
||||
* there's roundoff error we might do the wrong thing. So be sure that
|
||||
* the computations below form the same intermediate values in the same
|
||||
* order.
|
||||
*/
|
||||
if (aggstrategy == AGG_PLAIN)
|
||||
{
|
||||
@ -1074,8 +1075,8 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
|
||||
* restriction clauses) separately. We use approx_selectivity here for
|
||||
* speed --- in most cases, any errors won't affect the result much.
|
||||
*
|
||||
* Note: it's probably bogus to use the normal selectivity calculation here
|
||||
* when either the outer or inner path is a UniquePath.
|
||||
* Note: it's probably bogus to use the normal selectivity calculation
|
||||
* here when either the outer or inner path is a UniquePath.
|
||||
*/
|
||||
merge_selec = approx_selectivity(root, mergeclauses,
|
||||
path->jpath.jointype);
|
||||
@ -1095,22 +1096,22 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
|
||||
* but on the other hand we ignore the bookkeeping costs of mark/restore.
|
||||
* Not clear if it's worth developing a more refined model.
|
||||
*
|
||||
* The number of re-fetches can be estimated approximately as size of merge
|
||||
* join output minus size of inner relation. Assume that the distinct key
|
||||
* values are 1, 2, ..., and denote the number of values of each key in
|
||||
* the outer relation as m1, m2, ...; in the inner relation, n1, n2, ...
|
||||
* Then we have
|
||||
* The number of re-fetches can be estimated approximately as size of
|
||||
* merge join output minus size of inner relation. Assume that the
|
||||
* distinct key values are 1, 2, ..., and denote the number of values of
|
||||
* each key in the outer relation as m1, m2, ...; in the inner relation,
|
||||
* n1, n2, ... Then we have
|
||||
*
|
||||
* size of join = m1 * n1 + m2 * n2 + ...
|
||||
*
|
||||
* number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 * n1
|
||||
* + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner
|
||||
* number of rescanned tuples = (m1 - 1) * n1 + (m2 - 1) * n2 + ... = m1 *
|
||||
* n1 + m2 * n2 + ... - (n1 + n2 + ...) = size of join - size of inner
|
||||
* relation
|
||||
*
|
||||
* This equation works correctly for outer tuples having no inner match (nk =
|
||||
* 0), but not for inner tuples having no outer match (mk = 0); we are
|
||||
* effectively subtracting those from the number of rescanned tuples, when
|
||||
* we should not. Can we do better without expensive selectivity
|
||||
* This equation works correctly for outer tuples having no inner match
|
||||
* (nk = 0), but not for inner tuples having no outer match (mk = 0); we
|
||||
* are effectively subtracting those from the number of rescanned tuples,
|
||||
* when we should not. Can we do better without expensive selectivity
|
||||
* computations?
|
||||
*/
|
||||
if (IsA(outer_path, UniquePath))
|
||||
@ -1132,9 +1133,9 @@ cost_mergejoin(MergePath *path, PlannerInfo *root)
|
||||
* inputs that will actually need to be scanned. We use only the first
|
||||
* (most significant) merge clause for this purpose.
|
||||
*
|
||||
* Since this calculation is somewhat expensive, and will be the same for all
|
||||
* mergejoin paths associated with the merge clause, we cache the results
|
||||
* in the RestrictInfo node.
|
||||
* Since this calculation is somewhat expensive, and will be the same for
|
||||
* all mergejoin paths associated with the merge clause, we cache the
|
||||
* results in the RestrictInfo node.
|
||||
*/
|
||||
if (mergeclauses && path->jpath.jointype != JOIN_FULL)
|
||||
{
|
||||
@ -1300,8 +1301,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root)
|
||||
* restriction clauses) separately. We use approx_selectivity here for
|
||||
* speed --- in most cases, any errors won't affect the result much.
|
||||
*
|
||||
* Note: it's probably bogus to use the normal selectivity calculation here
|
||||
* when either the outer or inner path is a UniquePath.
|
||||
* Note: it's probably bogus to use the normal selectivity calculation
|
||||
* here when either the outer or inner path is a UniquePath.
|
||||
*/
|
||||
hash_selec = approx_selectivity(root, hashclauses,
|
||||
path->jpath.jointype);
|
||||
@ -1341,8 +1342,8 @@ cost_hashjoin(HashPath *path, PlannerInfo *root)
|
||||
* bucketsize estimated for any individual hashclause; this is undoubtedly
|
||||
* conservative.
|
||||
*
|
||||
* BUT: if inner relation has been unique-ified, we can assume it's good for
|
||||
* hashing. This is important both because it's the right answer, and
|
||||
* BUT: if inner relation has been unique-ified, we can assume it's good
|
||||
* for hashing. This is important both because it's the right answer, and
|
||||
* because we avoid contaminating the cache with a value that's wrong for
|
||||
* non-unique-ified paths.
|
||||
*/
|
||||
@ -1538,8 +1539,8 @@ cost_qual_eval_walker(Node *node, QualCost *total)
|
||||
* and so are boolean operators (AND, OR, NOT). Simplistic, but a lot
|
||||
* better than no model at all.
|
||||
*
|
||||
* Should we try to account for the possibility of short-circuit evaluation
|
||||
* of AND/OR?
|
||||
* Should we try to account for the possibility of short-circuit
|
||||
* evaluation of AND/OR?
|
||||
*/
|
||||
if (IsA(node, FuncExpr) ||
|
||||
IsA(node, OpExpr) ||
|
||||
@ -1564,8 +1565,8 @@ cost_qual_eval_walker(Node *node, QualCost *total)
|
||||
* (Sub-selects that can be executed as InitPlans have already been
|
||||
* removed from the expression.)
|
||||
*
|
||||
* An exception occurs when we have decided we can implement the subplan
|
||||
* by hashing.
|
||||
* An exception occurs when we have decided we can implement the
|
||||
* subplan by hashing.
|
||||
*
|
||||
*/
|
||||
SubPlan *subplan = (SubPlan *) node;
|
||||
@ -1760,12 +1761,12 @@ set_joinrel_size_estimates(PlannerInfo *root, RelOptInfo *rel,
|
||||
/*
|
||||
* Basically, we multiply size of Cartesian product by selectivity.
|
||||
*
|
||||
* If we are doing an outer join, take that into account: the output must be
|
||||
* at least as large as the non-nullable input. (Is there any chance of
|
||||
* being even smarter?)
|
||||
* If we are doing an outer join, take that into account: the output must
|
||||
* be at least as large as the non-nullable input. (Is there any chance
|
||||
* of being even smarter?)
|
||||
*
|
||||
* For JOIN_IN and variants, the Cartesian product is figured with respect to
|
||||
* a unique-ified input, and then we can clamp to the size of the other
|
||||
* For JOIN_IN and variants, the Cartesian product is figured with respect
|
||||
* to a unique-ified input, and then we can clamp to the size of the other
|
||||
* input.
|
||||
*/
|
||||
switch (jointype)
|
||||
@ -1893,8 +1894,8 @@ set_function_size_estimates(PlannerInfo *root, RelOptInfo *rel)
|
||||
/*
|
||||
* Estimate number of rows the function itself will return.
|
||||
*
|
||||
* XXX no idea how to do this yet; but we can at least check whether function
|
||||
* returns set or not...
|
||||
* XXX no idea how to do this yet; but we can at least check whether
|
||||
* function returns set or not...
|
||||
*/
|
||||
if (expression_returns_set(rte->funcexpr))
|
||||
rel->tuples = 1000;
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.192 2005/11/14 23:54:17 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/indxpath.c,v 1.193 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -262,8 +262,8 @@ find_usable_indexes(PlannerInfo *root, RelOptInfo *rel,
|
||||
* to imply the predicate. If so, we could use the index in the
|
||||
* current context.
|
||||
*
|
||||
* We set useful_predicate to true iff the predicate was proven using the
|
||||
* current set of clauses. This is needed to prevent matching a
|
||||
* We set useful_predicate to true iff the predicate was proven using
|
||||
* the current set of clauses. This is needed to prevent matching a
|
||||
* predOK index to an arm of an OR, which would be a legal but
|
||||
* pointlessly inefficient plan. (A better plan will be generated by
|
||||
* just scanning the predOK index alone, no OR.)
|
||||
@ -524,19 +524,19 @@ choose_bitmap_and(PlannerInfo *root, RelOptInfo *rel, List *paths)
|
||||
* always take the first, and sequentially add on paths that result in a
|
||||
* lower estimated cost.
|
||||
*
|
||||
* We also make some effort to detect directly redundant input paths, as can
|
||||
* happen if there are multiple possibly usable indexes. For this we look
|
||||
* only at plain IndexPath inputs, not at sub-OR clauses. And we consider
|
||||
* an index redundant if all its index conditions were already used by
|
||||
* earlier indexes. (We could use predicate_implied_by to have a more
|
||||
* intelligent, but much more expensive, check --- but in most cases
|
||||
* We also make some effort to detect directly redundant input paths, as
|
||||
* can happen if there are multiple possibly usable indexes. For this we
|
||||
* look only at plain IndexPath inputs, not at sub-OR clauses. And we
|
||||
* consider an index redundant if all its index conditions were already
|
||||
* used by earlier indexes. (We could use predicate_implied_by to have a
|
||||
* more intelligent, but much more expensive, check --- but in most cases
|
||||
* simple pointer equality should suffice, since after all the index
|
||||
* conditions are all coming from the same RestrictInfo lists.)
|
||||
*
|
||||
* XXX is there any risk of throwing away a useful partial index here because
|
||||
* we don't explicitly look at indpred? At least in simple cases, the
|
||||
* partial index will sort before competing non-partial indexes and so it
|
||||
* makes the right choice, but perhaps we need to work harder.
|
||||
* XXX is there any risk of throwing away a useful partial index here
|
||||
* because we don't explicitly look at indpred? At least in simple cases,
|
||||
* the partial index will sort before competing non-partial indexes and so
|
||||
* it makes the right choice, but perhaps we need to work harder.
|
||||
*
|
||||
* Note: outputting the selected sub-paths in selectivity order is a good
|
||||
* thing even if we weren't using that as part of the selection method,
|
||||
@ -920,8 +920,8 @@ check_partial_indexes(PlannerInfo *root, RelOptInfo *rel)
|
||||
* index. For now, the test only uses restriction clauses (those in
|
||||
* baserestrictinfo). --Nels, Dec '92
|
||||
*
|
||||
* XXX as of 7.1, equivalence class info *is* available. Consider improving
|
||||
* this code as foreseen by Nels.
|
||||
* XXX as of 7.1, equivalence class info *is* available. Consider
|
||||
* improving this code as foreseen by Nels.
|
||||
*/
|
||||
|
||||
foreach(ilist, rel->indexlist)
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.97 2005/10/25 20:30:30 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinpath.c,v 1.98 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -176,8 +176,8 @@ sort_inner_and_outer(PlannerInfo *root,
|
||||
* cheapest-startup-cost input paths later, and only if they don't need a
|
||||
* sort.
|
||||
*
|
||||
* If unique-ification is requested, do it and then handle as a plain inner
|
||||
* join.
|
||||
* If unique-ification is requested, do it and then handle as a plain
|
||||
* inner join.
|
||||
*/
|
||||
outer_path = outerrel->cheapest_total_path;
|
||||
inner_path = innerrel->cheapest_total_path;
|
||||
@ -512,8 +512,8 @@ match_unsorted_outer(PlannerInfo *root,
|
||||
|
||||
/*
|
||||
* Generate a mergejoin on the basis of sorting the cheapest inner.
|
||||
* Since a sort will be needed, only cheapest total cost matters.
|
||||
* (But create_mergejoin_path will do the right thing if
|
||||
* Since a sort will be needed, only cheapest total cost matters. (But
|
||||
* create_mergejoin_path will do the right thing if
|
||||
* inner_cheapest_total is already correctly sorted.)
|
||||
*/
|
||||
add_path(joinrel, (Path *)
|
||||
@ -804,9 +804,9 @@ select_mergejoin_clauses(RelOptInfo *joinrel,
|
||||
|
||||
/*
|
||||
* If processing an outer join, only use its own join clauses in the
|
||||
* merge. For inner joins we can use pushed-down clauses too.
|
||||
* (Note: we don't set have_nonmergeable_joinclause here because
|
||||
* pushed-down clauses will become otherquals not joinquals.)
|
||||
* merge. For inner joins we can use pushed-down clauses too. (Note:
|
||||
* we don't set have_nonmergeable_joinclause here because pushed-down
|
||||
* clauses will become otherquals not joinquals.)
|
||||
*/
|
||||
if (isouterjoin && restrictinfo->is_pushed_down)
|
||||
continue;
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.76 2005/10/15 02:49:20 momjian Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/joinrels.c,v 1.77 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -496,8 +496,9 @@ make_join_rel(PlannerInfo *root, RelOptInfo *rel1, RelOptInfo *rel2,
|
||||
* innerrel is exactly RHS; conversely JOIN_REVERSE_IN handles
|
||||
* RHS/LHS.
|
||||
*
|
||||
* JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS; conversely
|
||||
* JOIN_UNIQUE_INNER will work if innerrel is exactly RHS.
|
||||
* JOIN_UNIQUE_OUTER will work if outerrel is exactly RHS;
|
||||
* conversely JOIN_UNIQUE_INNER will work if innerrel is exactly
|
||||
* RHS.
|
||||
*
|
||||
* But none of these will work if we already found another IN that
|
||||
* needs to trigger here.
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
*
|
||||
*
|
||||
* IDENTIFICATION
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.76 2005/11/14 23:54:18 tgl Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/orindxpath.c,v 1.77 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -91,11 +91,10 @@ create_or_index_quals(PlannerInfo *root, RelOptInfo *rel)
|
||||
|
||||
/*
|
||||
* Find potentially interesting OR joinclauses. Note we must ignore any
|
||||
* joinclauses that are marked outerjoin_delayed, because they cannot
|
||||
* be pushed down to the per-relation level due to outer-join rules.
|
||||
* (XXX in some cases it might be possible to allow this, but it would
|
||||
* require substantially more bookkeeping about where the clause came
|
||||
* from.)
|
||||
* joinclauses that are marked outerjoin_delayed, because they cannot be
|
||||
* pushed down to the per-relation level due to outer-join rules. (XXX in
|
||||
* some cases it might be possible to allow this, but it would require
|
||||
* substantially more bookkeeping about where the clause came from.)
|
||||
*/
|
||||
foreach(i, rel->joininfo)
|
||||
{
|
||||
|
||||
@ -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.73 2005/10/15 02:49:20 momjian Exp $
|
||||
* $PostgreSQL: pgsql/src/backend/optimizer/path/pathkeys.c,v 1.74 2005/11/22 18:17:12 momjian Exp $
|
||||
*
|
||||
*-------------------------------------------------------------------------
|
||||
*/
|
||||
@ -125,8 +125,8 @@ add_equijoined_keys(PlannerInfo *root, RestrictInfo *restrictinfo)
|
||||
* structure. If we find both of them in the same equivalence set to
|
||||
* start with, we can quit immediately.
|
||||
*
|
||||
* This is a standard UNION-FIND problem, for which there exist better data
|
||||
* structures than simple lists. If this code ever proves to be a
|
||||
* This is a standard UNION-FIND problem, for which there exist better
|
||||
* data structures than simple lists. If this code ever proves to be a
|
||||
* bottleneck then it could be sped up --- but for now, simple is
|
||||
* beautiful.
|
||||
*/
|
||||
@ -255,9 +255,9 @@ generate_implied_equalities(PlannerInfo *root)
|
||||
* Match each item in the set with all that appear after it (it's
|
||||
* sufficient to generate A=B, need not process B=A too).
|
||||
*
|
||||
* A set containing only two items cannot imply any equalities beyond the
|
||||
* one that created the set, so we can skip this processing in that
|
||||
* case.
|
||||
* A set containing only two items cannot imply any equalities beyond
|
||||
* the one that created the set, so we can skip this processing in
|
||||
* that case.
|
||||
*/
|
||||
if (nitems >= 3)
|
||||
{
|
||||
@ -516,12 +516,12 @@ sub_generate_join_implications(PlannerInfo *root,
|
||||
* the join clause, since both were automatically generated in the
|
||||
* cases we care about.
|
||||
*
|
||||
* XXX currently this may fail to match in cross-type cases because
|
||||
* the COALESCE will contain typecast operations while the join
|
||||
* clause may not (if there is a cross-type mergejoin operator
|
||||
* available for the two column types). Is it OK to strip implicit
|
||||
* coercions from the COALESCE arguments? What of the sortops in
|
||||
* such cases?
|
||||
* XXX currently this may fail to match in cross-type cases
|
||||
* because the COALESCE will contain typecast operations while the
|
||||
* join clause may not (if there is a cross-type mergejoin
|
||||
* operator available for the two column types). Is it OK to strip
|
||||
* implicit coercions from the COALESCE arguments? What of the
|
||||
* sortops in such cases?
|
||||
*/
|
||||
if (equal(leftop, cfirst) &&
|
||||
equal(rightop, csecond) &&
|
||||
@ -1151,8 +1151,8 @@ build_join_pathkeys(PlannerInfo *root,
|
||||
* here! The inner-rel vars we used to need to add are *already* part of
|
||||
* the outer pathkey!
|
||||
*
|
||||
* We do, however, need to truncate the pathkeys list, since it may contain
|
||||
* pathkeys that were useful for forming this joinrel but are
|
||||
* We do, however, need to truncate the pathkeys list, since it may
|
||||
* contain pathkeys that were useful for forming this joinrel but are
|
||||
* uninteresting to higher levels.
|
||||
*/
|
||||
return truncate_useless_pathkeys(root, joinrel, outer_pathkeys);
|
||||
@ -1299,8 +1299,8 @@ find_mergeclauses_for_pathkeys(PlannerInfo *root,
|
||||
* any redundant mergeclauses from the input list. However, in
|
||||
* outer-join scenarios there might be multiple matches. An example is
|
||||
*
|
||||
* select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1 =
|
||||
* b.v2;
|
||||
* select * from a full join b on a.v1 = b.v1 and a.v2 = b.v2 and a.v1
|
||||
* = b.v2;
|
||||
*
|
||||
* Given the pathkeys ((a.v1), (a.v2)) it is okay to return all three
|
||||
* clauses (in the order a.v1=b.v1, a.v1=b.v2, a.v2=b.v2) and indeed
|
||||
|
||||
Reference in New Issue
Block a user