From d7471402794266078953f1bd113dab4913d631a1 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 11 Jun 2009 14:49:15 +0000 Subject: 8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew. --- src/backend/parser/parse_clause.c | 128 +++++++++++++++++++------------------- 1 file changed, 64 insertions(+), 64 deletions(-) (limited to 'src/backend/parser/parse_clause.c') diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c index 2deffa9139..8a42f5bf0a 100644 --- a/src/backend/parser/parse_clause.c +++ b/src/backend/parser/parse_clause.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_clause.c,v 1.188 2009/04/04 21:12:31 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_clause.c,v 1.189 2009/06/11 14:49:00 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -42,7 +42,7 @@ #define DISTINCT_ON_CLAUSE 2 #define PARTITION_CLAUSE 3 -static const char * const clauseText[] = { +static const char *const clauseText[] = { "ORDER BY", "GROUP BY", "DISTINCT ON", @@ -75,8 +75,8 @@ static Node *buildMergedJoinVar(ParseState *pstate, JoinType jointype, Var *l_colvar, Var *r_colvar); static TargetEntry *findTargetlistEntry(ParseState *pstate, Node *node, List **tlist, int clause); -static int get_matching_location(int sortgroupref, - List *sortgrouprefs, List *exprs); +static int get_matching_location(int sortgroupref, + List *sortgrouprefs, List *exprs); static List *addTargetToSortList(ParseState *pstate, TargetEntry *tle, List *sortlist, List *targetlist, SortBy *sortby, bool resolveUnknown); @@ -414,7 +414,7 @@ transformJoinOnClause(ParseState *pstate, JoinExpr *j, errmsg("JOIN/ON clause refers to \"%s\", which is not part of JOIN", rt_fetch(varno, pstate->p_rtable)->eref->aliasname), parser_errposition(pstate, - locate_var_of_relation(result, varno, 0)))); + locate_var_of_relation(result, varno, 0)))); } bms_free(clause_varnos); @@ -493,7 +493,7 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r) (errcode(ERRCODE_SYNTAX_ERROR), errmsg("subquery in FROM cannot have SELECT INTO"), parser_errposition(pstate, - exprLocation((Node *) query->intoClause)))); + exprLocation((Node *) query->intoClause)))); /* * The subquery cannot make use of any variables from FROM items created @@ -515,7 +515,7 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r) (errcode(ERRCODE_INVALID_COLUMN_REFERENCE), errmsg("subquery in FROM cannot refer to other relations of same query level"), parser_errposition(pstate, - locate_var_of_level((Node *) query, 1)))); + locate_var_of_level((Node *) query, 1)))); } /* @@ -584,7 +584,7 @@ transformRangeFunction(ParseState *pstate, RangeFunction *r) checkExprHasWindowFuncs(funcexpr)) ereport(ERROR, (errcode(ERRCODE_WINDOWING_ERROR), - errmsg("cannot use window function in function expression in FROM"), + errmsg("cannot use window function in function expression in FROM"), parser_errposition(pstate, locate_windowfunc(funcexpr)))); @@ -649,7 +649,7 @@ transformFromClauseItem(ParseState *pstate, Node *n, if (IsA(n, RangeVar)) { /* Plain relation reference, or perhaps a CTE reference */ - RangeVar *rv = (RangeVar *) n; + RangeVar *rv = (RangeVar *) n; RangeTblRef *rtr; RangeTblEntry *rte = NULL; int rtindex; @@ -658,7 +658,7 @@ transformFromClauseItem(ParseState *pstate, Node *n, if (!rv->schemaname) { CommonTableExpr *cte; - Index levelsup; + Index levelsup; cte = scanNameSpaceForCTE(pstate, rv->relname, &levelsup); if (cte) @@ -1432,11 +1432,11 @@ transformGroupClause(ParseState *pstate, List *grouplist, * info from the (first) matching ORDER BY item. This means that if * you write something like "GROUP BY foo ORDER BY foo USING <<<", the * GROUP BY operation silently takes on the equality semantics implied - * by the ORDER BY. There are two reasons to do this: it improves - * the odds that we can implement both GROUP BY and ORDER BY with a - * single sort step, and it allows the user to choose the equality - * semantics used by GROUP BY, should she be working with a datatype - * that has more than one equality operator. + * by the ORDER BY. There are two reasons to do this: it improves the + * odds that we can implement both GROUP BY and ORDER BY with a single + * sort step, and it allows the user to choose the equality semantics + * used by GROUP BY, should she be working with a datatype that has + * more than one equality operator. */ if (tle->ressortgroupref > 0) { @@ -1456,8 +1456,8 @@ transformGroupClause(ParseState *pstate, List *grouplist, } /* - * If no match in ORDER BY, just add it to the result using - * default sort/group semantics. + * If no match in ORDER BY, just add it to the result using default + * sort/group semantics. */ if (!found) result = addTargetToGroupList(pstate, tle, @@ -1516,10 +1516,10 @@ transformWindowDefinitions(ParseState *pstate, foreach(lc, windowdefs) { - WindowDef *windef = (WindowDef *) lfirst(lc); + WindowDef *windef = (WindowDef *) lfirst(lc); WindowClause *refwc = NULL; - List *partitionClause; - List *orderClause; + List *partitionClause; + List *orderClause; WindowClause *wc; winref++; @@ -1550,8 +1550,8 @@ transformWindowDefinitions(ParseState *pstate, /* * Transform PARTITION and ORDER specs, if any. These are treated - * exactly like top-level GROUP BY and ORDER BY clauses, including - * the special handling of nondefault operator semantics. + * exactly like top-level GROUP BY and ORDER BY clauses, including the + * special handling of nondefault operator semantics. */ orderClause = transformSortClause(pstate, windef->orderClause, @@ -1573,19 +1573,19 @@ transformWindowDefinitions(ParseState *pstate, /* * Per spec, a windowdef that references a previous one copies the * previous partition clause (and mustn't specify its own). It can - * specify its own ordering clause. but only if the previous one - * had none. It always specifies its own frame clause, and the - * previous one must not have a frame clause. (Yeah, it's bizarre - * that each of these cases works differently, but SQL:2008 says so; - * see 7.11 syntax rule 10 and general rule 1.) + * specify its own ordering clause. but only if the previous one had + * none. It always specifies its own frame clause, and the previous + * one must not have a frame clause. (Yeah, it's bizarre that each of + * these cases works differently, but SQL:2008 says so; see 7.11 + * syntax rule 10 and general rule 1.) */ if (refwc) { if (partitionClause) ereport(ERROR, (errcode(ERRCODE_WINDOWING_ERROR), - errmsg("cannot override PARTITION BY clause of window \"%s\"", - windef->refname), + errmsg("cannot override PARTITION BY clause of window \"%s\"", + windef->refname), parser_errposition(pstate, windef->location))); wc->partitionClause = copyObject(refwc->partitionClause); } @@ -1596,8 +1596,8 @@ transformWindowDefinitions(ParseState *pstate, if (orderClause && refwc->orderClause) ereport(ERROR, (errcode(ERRCODE_WINDOWING_ERROR), - errmsg("cannot override ORDER BY clause of window \"%s\"", - windef->refname), + errmsg("cannot override ORDER BY clause of window \"%s\"", + windef->refname), parser_errposition(pstate, windef->location))); if (orderClause) { @@ -1652,19 +1652,19 @@ transformDistinctClause(ParseState *pstate, ListCell *tlitem; /* - * The distinctClause should consist of all ORDER BY items followed - * by all other non-resjunk targetlist items. There must not be any - * resjunk ORDER BY items --- that would imply that we are sorting - * by a value that isn't necessarily unique within a DISTINCT group, - * so the results wouldn't be well-defined. This construction - * ensures we follow the rule that sortClause and distinctClause match; - * in fact the sortClause will always be a prefix of distinctClause. + * The distinctClause should consist of all ORDER BY items followed by all + * other non-resjunk targetlist items. There must not be any resjunk + * ORDER BY items --- that would imply that we are sorting by a value that + * isn't necessarily unique within a DISTINCT group, so the results + * wouldn't be well-defined. This construction ensures we follow the rule + * that sortClause and distinctClause match; in fact the sortClause will + * always be a prefix of distinctClause. * - * Note a corner case: the same TLE could be in the ORDER BY list - * multiple times with different sortops. We have to include it in - * the distinctClause the same way to preserve the prefix property. - * The net effect will be that the TLE value will be made unique - * according to both sortops. + * Note a corner case: the same TLE could be in the ORDER BY list multiple + * times with different sortops. We have to include it in the + * distinctClause the same way to preserve the prefix property. The net + * effect will be that the TLE value will be made unique according to both + * sortops. */ foreach(slitem, sortClause) { @@ -1681,8 +1681,8 @@ transformDistinctClause(ParseState *pstate, } /* - * Now add any remaining non-resjunk tlist items, using default - * sort/group semantics for their data types. + * Now add any remaining non-resjunk tlist items, using default sort/group + * semantics for their data types. */ foreach(tlitem, *targetlist) { @@ -1724,11 +1724,11 @@ transformDistinctOnClause(ParseState *pstate, List *distinctlist, /* * Add all the DISTINCT ON expressions to the tlist (if not already - * present, they are added as resjunk items). Assign sortgroupref - * numbers to them, and make a list of these numbers. (NB: we rely - * below on the sortgrouprefs list being one-for-one with the original - * distinctlist. Also notice that we could have duplicate DISTINCT ON - * expressions and hence duplicate entries in sortgrouprefs.) + * present, they are added as resjunk items). Assign sortgroupref numbers + * to them, and make a list of these numbers. (NB: we rely below on the + * sortgrouprefs list being one-for-one with the original distinctlist. + * Also notice that we could have duplicate DISTINCT ON expressions and + * hence duplicate entries in sortgrouprefs.) */ foreach(lc, distinctlist) { @@ -1743,12 +1743,12 @@ transformDistinctOnClause(ParseState *pstate, List *distinctlist, } /* - * If the user writes both DISTINCT ON and ORDER BY, adopt the - * sorting semantics from ORDER BY items that match DISTINCT ON - * items, and also adopt their column sort order. We insist that - * the distinctClause and sortClause match, so throw error if we - * find the need to add any more distinctClause items after we've - * skipped an ORDER BY item that wasn't in DISTINCT ON. + * If the user writes both DISTINCT ON and ORDER BY, adopt the sorting + * semantics from ORDER BY items that match DISTINCT ON items, and also + * adopt their column sort order. We insist that the distinctClause and + * sortClause match, so throw error if we find the need to add any more + * distinctClause items after we've skipped an ORDER BY item that wasn't + * in DISTINCT ON. */ skipped_sortitem = false; foreach(lc, sortClause) @@ -1762,9 +1762,9 @@ transformDistinctOnClause(ParseState *pstate, List *distinctlist, (errcode(ERRCODE_INVALID_COLUMN_REFERENCE), errmsg("SELECT DISTINCT ON expressions must match initial ORDER BY expressions"), parser_errposition(pstate, - get_matching_location(scl->tleSortGroupRef, - sortgrouprefs, - distinctlist)))); + get_matching_location(scl->tleSortGroupRef, + sortgrouprefs, + distinctlist)))); else result = lappend(result, copyObject(scl)); } @@ -1774,8 +1774,8 @@ transformDistinctOnClause(ParseState *pstate, List *distinctlist, /* * Now add any remaining DISTINCT ON items, using default sort/group - * semantics for their data types. (Note: this is pretty questionable; - * if the ORDER BY list doesn't include all the DISTINCT ON items and more + * semantics for their data types. (Note: this is pretty questionable; if + * the ORDER BY list doesn't include all the DISTINCT ON items and more * besides, you certainly aren't using DISTINCT ON in the intended way, * and you probably aren't going to get consistent results. It might be * better to throw an error or warning here. But historically we've @@ -1870,9 +1870,9 @@ addTargetToSortList(ParseState *pstate, TargetEntry *tle, * Rather than clutter the API of get_sort_group_operators and the other * functions we're about to use, make use of error context callback to * mark any error reports with a parse position. We point to the operator - * location if present, else to the expression being sorted. (NB: use - * the original untransformed expression here; the TLE entry might well - * point at a duplicate expression in the regular SELECT list.) + * location if present, else to the expression being sorted. (NB: use the + * original untransformed expression here; the TLE entry might well point + * at a duplicate expression in the regular SELECT list.) */ location = sortby->location; if (location < 0) -- cgit v1.2.1