diff options
Diffstat (limited to 'src/backend/parser')
| -rw-r--r-- | src/backend/parser/analyze.c | 38 | ||||
| -rw-r--r-- | src/backend/parser/parse_clause.c | 22 | ||||
| -rw-r--r-- | src/backend/parser/parse_coerce.c | 20 | ||||
| -rw-r--r-- | src/backend/parser/parse_expr.c | 14 | ||||
| -rw-r--r-- | src/backend/parser/parse_func.c | 50 | ||||
| -rw-r--r-- | src/backend/parser/parse_oper.c | 8 | ||||
| -rw-r--r-- | src/backend/parser/parse_relation.c | 16 | ||||
| -rw-r--r-- | src/backend/parser/parse_target.c | 8 |
8 files changed, 88 insertions, 88 deletions
diff --git a/src/backend/parser/analyze.c b/src/backend/parser/analyze.c index 46dbb3f1488..da8629bbb36 100644 --- a/src/backend/parser/analyze.c +++ b/src/backend/parser/analyze.c @@ -6,7 +6,7 @@ * Portions Copyright (c) 1996-2005, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * - * $PostgreSQL: pgsql/src/backend/parser/analyze.c,v 1.326 2005/10/15 02:49:21 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/analyze.c,v 1.326.2.1 2005/11/22 18:23:12 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -1108,8 +1108,8 @@ transformInhRelation(ParseState *pstate, CreateStmtContext *cxt, /* * Create a new inherited column. * - * For constraints, ONLY the NOT NULL constraint is inherited by the new - * column definition per SQL99. + * For constraints, ONLY the NOT NULL constraint is inherited by the + * new column definition per SQL99. */ def = makeNode(ColumnDef); def->colname = pstrdup(attributeName); @@ -1353,8 +1353,8 @@ transformIndexConstraints(ParseState *pstate, CreateStmtContext *cxt) * strict reading of SQL92 would suggest raising an error instead, but * that strikes me as too anal-retentive. - tgl 2001-02-14 * - * XXX in ALTER TABLE case, it'd be nice to look for duplicate pre-existing - * indexes, too. + * XXX in ALTER TABLE case, it'd be nice to look for duplicate + * pre-existing indexes, too. */ cxt->alist = NIL; if (cxt->pkey != NULL) @@ -1744,8 +1744,8 @@ transformRuleStmt(ParseState *pstate, RuleStmt *stmt, * For efficiency's sake, add OLD to the rule action's jointree * only if it was actually referenced in the statement or qual. * - * For INSERT, NEW is not really a relation (only a reference to the - * to-be-inserted tuple) and should never be added to the + * For INSERT, NEW is not really a relation (only a reference to + * the to-be-inserted tuple) and should never be added to the * jointree. * * For UPDATE, we treat NEW as being another kind of reference to @@ -1967,10 +1967,10 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt) * make lists of the dummy vars and their names for use in parsing ORDER * BY. * - * Note: we use leftmostRTI as the varno of the dummy variables. It shouldn't - * matter too much which RT index they have, as long as they have one that - * corresponds to a real RT entry; else funny things may happen when the - * tree is mashed by rule rewriting. + * Note: we use leftmostRTI as the varno of the dummy variables. It + * shouldn't matter too much which RT index they have, as long as they + * have one that corresponds to a real RT entry; else funny things may + * happen when the tree is mashed by rule rewriting. */ qry->targetList = NIL; targetvars = NIL; @@ -2005,9 +2005,9 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt) /* * Handle SELECT INTO/CREATE TABLE AS. * - * Any column names from CREATE TABLE AS need to be attached to both the top - * level and the leftmost subquery. We do not do this earlier because we - * do *not* want the targetnames list to be affected. + * Any column names from CREATE TABLE AS need to be attached to both the + * top level and the leftmost subquery. We do not do this earlier because + * we do *not* want the targetnames list to be affected. */ qry->into = into; if (intoColNames) @@ -2022,9 +2022,9 @@ transformSetOperationStmt(ParseState *pstate, SelectStmt *stmt) * output columns visible. A Join RTE node is handy for this, since we * can easily control the Vars generated upon matches. * - * Note: we don't yet do anything useful with such cases, but at least "ORDER - * BY upper(foo)" will draw the right error message rather than "foo not - * found". + * Note: we don't yet do anything useful with such cases, but at least + * "ORDER BY upper(foo)" will draw the right error message rather than + * "foo not found". */ jrte = addRangeTableEntryForJoin(NULL, targetnames, @@ -2140,8 +2140,8 @@ transformSetOperationTree(ParseState *pstate, SelectStmt *stmt) /* * Transform SelectStmt into a Query. * - * Note: previously transformed sub-queries don't affect the parsing of - * this sub-query, because they are not in the toplevel pstate's + * Note: previously transformed sub-queries don't affect the parsing + * of this sub-query, because they are not in the toplevel pstate's * namespace list. */ selectList = parse_sub_analyze((Node *) stmt, pstate); diff --git a/src/backend/parser/parse_clause.c b/src/backend/parser/parse_clause.c index 95e1045ba2d..173d1723b3f 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.143 2005/10/15 02:49:22 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_clause.c,v 1.143.2.1 2005/11/22 18:23:13 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -172,9 +172,9 @@ setTargetTable(ParseState *pstate, RangeVar *relation, * instead mark target table as requiring exactly the specified * permissions. * - * If we find an explicit reference to the rel later during parse analysis, - * scanRTEForColumn will add the ACL_SELECT bit back again. That can't - * happen for INSERT but it is possible for UPDATE and DELETE. + * If we find an explicit reference to the rel later during parse + * analysis, scanRTEForColumn will add the ACL_SELECT bit back again. That + * can't happen for INSERT but it is possible for UPDATE and DELETE. */ rte->requiredPerms = requiredPerms; @@ -462,8 +462,8 @@ transformRangeSubselect(ParseState *pstate, RangeSubselect *r) * XXX this will need further work to support SQL99's LATERAL() feature, * wherein such references would indeed be legal. * - * We can skip groveling through the subquery if there's not anything visible - * in the current query. Also note that outer references are OK. + * We can skip groveling through the subquery if there's not anything + * visible in the current query. Also note that outer references are OK. */ if (pstate->p_relnamespace || pstate->p_varnamespace) { @@ -1193,8 +1193,8 @@ findTargetlistEntry(ParseState *pstate, Node *node, List **tlist, int clause) * than one column name exposed by FROM, colNameToVar will * ereport(ERROR). That's just what we want here. * - * Small tweak for 7.4.3: ignore matches in upper query levels. This - * effectively changes the search order for bare names to (1) + * Small tweak for 7.4.3: ignore matches in upper query levels. + * This effectively changes the search order for bare names to (1) * local FROM variables, (2) local targetlist aliases, (3) outer * FROM variables, whereas before it was (1) (3) (2). SQL92 and * SQL99 do not allow GROUPing BY an outer reference, so this @@ -1474,9 +1474,9 @@ transformDistinctClause(ParseState *pstate, List *distinctlist, * DISTINCT values to the sort list, much as we did above for ordinary * DISTINCT fields. * - * Actually, it'd be OK for the common prefixes of the two lists to match - * in any order, but implementing that check seems like more trouble - * than it's worth. + * Actually, it'd be OK for the common prefixes of the two lists to + * match in any order, but implementing that check seems like more + * trouble than it's worth. */ ListCell *nextsortlist = list_head(*sortClause); diff --git a/src/backend/parser/parse_coerce.c b/src/backend/parser/parse_coerce.c index 3bee3c31ad5..c3f60292c3e 100644 --- a/src/backend/parser/parse_coerce.c +++ b/src/backend/parser/parse_coerce.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.132 2005/10/15 02:49:22 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_coerce.c,v 2.132.2.1 2005/11/22 18:23:13 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -180,9 +180,9 @@ coerce_type(ParseState *pstate, Node *node, * length checks, which is not always what we want here. Any * length constraint will be applied later by our caller. * - * Note that we call stringTypeDatum using the domain's pg_type row, - * if it's a domain. This works because the domain row has the - * same typinput and typelem as the base type --- ugly... + * Note that we call stringTypeDatum using the domain's pg_type + * row, if it's a domain. This works because the domain row has + * the same typinput and typelem as the base type --- ugly... */ newcon->constvalue = stringTypeDatum(targetType, val, -1); } @@ -1670,12 +1670,12 @@ find_coercion_pathway(Oid targetTypeId, Oid sourceTypeId, * array types. If so, and if the element types have a suitable cast, * use array_type_coerce() or array_type_length_coerce(). * - * Hack: disallow coercions to oidvector and int2vector, which otherwise - * tend to capture coercions that should go to "real" array types. We - * want those types to be considered "real" arrays for many purposes, - * but not this one. (Also, array_type_coerce isn't guaranteed to - * produce an output that meets the restrictions of these datatypes, - * such as being 1-dimensional.) + * Hack: disallow coercions to oidvector and int2vector, which + * otherwise tend to capture coercions that should go to "real" array + * types. We want those types to be considered "real" arrays for many + * purposes, but not this one. (Also, array_type_coerce isn't + * guaranteed to produce an output that meets the restrictions of + * these datatypes, such as being 1-dimensional.) */ Oid targetElemType; Oid sourceElemType; diff --git a/src/backend/parser/parse_expr.c b/src/backend/parser/parse_expr.c index 9146887adc3..7045c3af5b5 100644 --- a/src/backend/parser/parse_expr.c +++ b/src/backend/parser/parse_expr.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_expr.c,v 1.185.2.1 2005/11/18 23:08:13 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_expr.c,v 1.185.2.2 2005/11/22 18:23:13 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -365,10 +365,10 @@ transformColumnRef(ParseState *pstate, ColumnRef *cref) /* * Not known as a column of any range-table entry. * - * Consider the possibility that it's VALUE in a domain check - * expression. (We handle VALUE as a name, not a keyword, - * to avoid breaking a lot of applications that have used - * VALUE as a column name in the past.) + * Consider the possibility that it's VALUE in a domain + * check expression. (We handle VALUE as a name, not a + * keyword, to avoid breaking a lot of applications that + * have used VALUE as a column name in the past.) */ if (pstate->p_value_substitute != NULL && strcmp(name, "value") == 0) @@ -781,8 +781,8 @@ transformFuncCall(ParseState *pstate, FuncCall *fn) * Transform the list of arguments. We use a shallow list copy and then * transform-in-place to avoid O(N^2) behavior from repeated lappend's. * - * XXX: repeated lappend() would no longer result in O(n^2) behavior; worth - * reconsidering this design? + * XXX: repeated lappend() would no longer result in O(n^2) behavior; + * worth reconsidering this design? */ targs = list_copy(fn->args); foreach(args, targs) diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c index a3a42326487..8c15203433e 100644 --- a/src/backend/parser/parse_func.c +++ b/src/backend/parser/parse_func.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_func.c,v 1.182 2005/10/15 02:49:22 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_func.c,v 1.182.2.1 2005/11/22 18:23:14 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -88,11 +88,11 @@ ParseFuncOrColumn(ParseState *pstate, List *funcname, List *fargs, /* * Extract arg type info in preparation for function lookup. * - * If any arguments are Param markers of type VOID, we discard them from the - * parameter list. This is a hack to allow the JDBC driver to not have to - * distinguish "input" and "output" parameter symbols while parsing - * function-call constructs. We can't use foreach() because we may modify - * the list ... + * If any arguments are Param markers of type VOID, we discard them from + * the parameter list. This is a hack to allow the JDBC driver to not + * have to distinguish "input" and "output" parameter symbols while + * parsing function-call constructs. We can't use foreach() because we + * may modify the list ... */ nargs = 0; for (l = list_head(fargs); l != NULL; l = nextl) @@ -502,10 +502,10 @@ func_select_candidate(int nargs, /* * Still too many candidates? Try assigning types for the unknown columns. * - * NOTE: for a binary operator with one unknown and one non-unknown input, we - * already tried the heuristic of looking for a candidate with the known - * input type on both sides (see binary_oper_exact()). That's essentially - * a special case of the general algorithm we try next. + * NOTE: for a binary operator with one unknown and one non-unknown input, + * we already tried the heuristic of looking for a candidate with the + * known input type on both sides (see binary_oper_exact()). That's + * essentially a special case of the general algorithm we try next. * * We do this by examining each unknown argument position to see if we can * determine a "type category" for it. If any candidate has an input @@ -518,10 +518,10 @@ func_select_candidate(int nargs, * If we are able to determine a type category, also notice whether any of * the candidates takes a preferred datatype within the category. * - * Having completed this examination, remove candidates that accept the wrong - * category at any unknown position. Also, if at least one candidate - * accepted a preferred type at a position, remove candidates that accept - * non-preferred types. + * Having completed this examination, remove candidates that accept the + * wrong category at any unknown position. Also, if at least one + * candidate accepted a preferred type at a position, remove candidates + * that accept non-preferred types. * * If we are down to one candidate at the end, we win. */ @@ -708,20 +708,20 @@ func_get_detail(List *funcname, * as "text(name(varchar))" which the code below this point is * entirely capable of selecting. * - * "Trivial" coercions are ones that involve binary-compatible types and - * ones that are coercing a previously-unknown-type literal constant - * to a specific type. + * "Trivial" coercions are ones that involve binary-compatible types + * and ones that are coercing a previously-unknown-type literal + * constant to a specific type. * * The reason we can restrict our check to binary-compatible coercions * here is that we expect non-binary-compatible coercions to have an * implementation function named after the target type. That function * will be found by normal lookup if appropriate. * - * NB: it's important that this code stays in sync with what coerce_type - * can do, because the caller will try to apply coerce_type if we - * return FUNCDETAIL_COERCION. If we return that result for something - * coerce_type can't handle, we'll cause infinite recursion between - * this module and coerce_type! + * NB: it's important that this code stays in sync with what + * coerce_type can do, because the caller will try to apply + * coerce_type if we return FUNCDETAIL_COERCION. If we return that + * result for something coerce_type can't handle, we'll cause infinite + * recursion between this module and coerce_type! */ if (nargs == 1 && fargs != NIL) { @@ -983,9 +983,9 @@ ParseComplexProjection(ParseState *pstate, char *funcname, Node *first_arg) /* * Else do it the hard way with get_expr_result_type(). * - * If it's a Var of type RECORD, we have to work even harder: we have to find - * what the Var refers to, and pass that to get_expr_result_type. That - * task is handled by expandRecordVariable(). + * If it's a Var of type RECORD, we have to work even harder: we have to + * find what the Var refers to, and pass that to get_expr_result_type. + * That task is handled by expandRecordVariable(). */ if (IsA(first_arg, Var) && ((Var *) first_arg)->vartype == RECORDOID) diff --git a/src/backend/parser/parse_oper.c b/src/backend/parser/parse_oper.c index 764f729529f..6329ae5f927 100644 --- a/src/backend/parser/parse_oper.c +++ b/src/backend/parser/parse_oper.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_oper.c,v 1.82 2005/10/15 02:49:22 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_oper.c,v 1.82.2.1 2005/11/22 18:23:14 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -702,9 +702,9 @@ left_oper(List *op, Oid arg, bool noError) * First, quickly check to see if there is an exactly matching * operator (there can be only one such entry in the list). * - * The returned list has args in the form (0, oprright). Move the useful - * data into args[0] to keep oper_select_candidate simple. XXX we are - * assuming here that we may scribble on the list! + * The returned list has args in the form (0, oprright). Move the + * useful data into args[0] to keep oper_select_candidate simple. XXX + * we are assuming here that we may scribble on the list! */ FuncCandidateList clisti; diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index efa9b49931c..2ed0a523501 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_relation.c,v 1.116 2005/10/26 19:21:54 tgl Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_relation.c,v 1.116.2.1 2005/11/22 18:23:14 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -301,10 +301,10 @@ scanRTEForColumn(ParseState *pstate, RangeTblEntry *rte, char *colname) * will be empty strings that cannot match any legal SQL identifier, so we * don't bother to test for that case here. * - * Should this somehow go wrong and we try to access a dropped column, we'll - * still catch it by virtue of the checks in get_rte_attribute_type(), - * which is called by make_var(). That routine has to do a cache lookup - * anyway, so the check there is cheap. + * Should this somehow go wrong and we try to access a dropped column, + * we'll still catch it by virtue of the checks in + * get_rte_attribute_type(), which is called by make_var(). That routine + * has to do a cache lookup anyway, so the check there is cheap. */ foreach(c, rte->eref->colnames) { @@ -1007,9 +1007,9 @@ addImplicitRTE(ParseState *pstate, RangeVar *relation) /* * Note that we set inFromCl true, so that the RTE will be listed - * explicitly if the parsetree is ever decompiled by ruleutils.c. - * This provides a migration path for views/rules that were originally - * written with implicit-RTE syntax. + * explicitly if the parsetree is ever decompiled by ruleutils.c. This + * provides a migration path for views/rules that were originally written + * with implicit-RTE syntax. */ rte = addRangeTableEntry(pstate, relation, NULL, false, true); /* Add to joinlist and relnamespace, but not varnamespace */ diff --git a/src/backend/parser/parse_target.c b/src/backend/parser/parse_target.c index 88c29ebf1e4..4290045baab 100644 --- a/src/backend/parser/parse_target.c +++ b/src/backend/parser/parse_target.c @@ -8,7 +8,7 @@ * * * IDENTIFICATION - * $PostgreSQL: pgsql/src/backend/parser/parse_target.c,v 1.138 2005/10/15 02:49:22 momjian Exp $ + * $PostgreSQL: pgsql/src/backend/parser/parse_target.c,v 1.138.2.1 2005/11/22 18:23:14 momjian Exp $ * *------------------------------------------------------------------------- */ @@ -808,9 +808,9 @@ ExpandIndirectionStar(ParseState *pstate, A_Indirection *ind) * lookup_rowtype_tupdesc(), which will almost certainly fail as well, but * it will give an appropriate error message. * - * If it's a Var of type RECORD, we have to work even harder: we have to find - * what the Var refers to, and pass that to get_expr_result_type. That - * task is handled by expandRecordVariable(). + * If it's a Var of type RECORD, we have to work even harder: we have to + * find what the Var refers to, and pass that to get_expr_result_type. + * That task is handled by expandRecordVariable(). */ if (IsA(expr, Var) && ((Var *) expr)->vartype == RECORDOID) |