diff options
Diffstat (limited to 'src/backend/parser')
-rw-r--r-- | src/backend/parser/gram.y | 28 | ||||
-rw-r--r-- | src/backend/parser/parse_relation.c | 6 | ||||
-rw-r--r-- | src/backend/parser/parse_utilcmd.c | 6 |
3 files changed, 19 insertions, 21 deletions
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y index ec693734f51..73c446a9071 100644 --- a/src/backend/parser/gram.y +++ b/src/backend/parser/gram.y @@ -21,8 +21,6 @@ * NOTES * CAPITALS are used to represent terminal symbols. * non-capitals are used to represent non-terminals. - * SQL92-specific syntax is separated from plain SQL/Postgres syntax - * to help isolate the non-extensible portions of the parser. * * In general, nothing in this file should initiate database accesses * nor depend on changeable state (such as SET variables). If you do @@ -1281,7 +1279,7 @@ schema_stmt: * * Set PG internal variable * SET name TO 'var_value' - * Include SQL92 syntax (thomas 1997-10-22): + * Include SQL syntax (thomas 1997-10-22): * SET TIME ZONE 'var_value' * *****************************************************************************/ @@ -2780,7 +2778,7 @@ ColConstraint: * to make it explicit. * - thomas 1998-09-13 * - * WITH NULL and NULL are not SQL92-standard syntax elements, + * WITH NULL and NULL are not SQL-standard syntax elements, * so leave them out. Use DEFAULT NULL to explicitly indicate * that a column may have that value. WITH NULL leads to * shift/reduce conflicts with WITH TIME ZONE anyway. @@ -9159,7 +9157,7 @@ select_clause: * As with select_no_parens, simple_select cannot have outer parentheses, * but can have parenthesized subclauses. * - * Note that sort clauses cannot be included at this level --- SQL92 requires + * Note that sort clauses cannot be included at this level --- SQL requires * SELECT foo UNION SELECT bar ORDER BY baz * to be parsed as * (SELECT foo UNION SELECT bar) ORDER BY baz @@ -9660,7 +9658,7 @@ table_ref: relation_expr opt_alias_clause /* * It may seem silly to separate joined_table from table_ref, but there is - * method in SQL92's madness: if you don't do it this way you get reduce- + * method in SQL's madness: if you don't do it this way you get reduce- * reduce conflicts, because it's not clear to the parser generator whether * to expect alias_clause after ')' or not. For the same reason we must * treat 'JOIN' and 'join_type JOIN' separately, rather than allowing @@ -9959,7 +9957,7 @@ TableFuncElement: ColId Typename opt_collate_clause /***************************************************************************** * * Type syntax - * SQL92 introduces a large amount of type-specific syntax. + * SQL introduces a large amount of type-specific syntax. * Define individual clauses to handle these cases, and use * the generic case to handle regular type-extensible Postgres syntax. * - thomas 1997-10-10 @@ -10085,7 +10083,7 @@ opt_type_modifiers: '(' expr_list ')' { $$ = $2; } ; /* - * SQL92 numeric data types + * SQL numeric data types */ Numeric: INT_P { @@ -10175,7 +10173,7 @@ opt_float: '(' Iconst ')' ; /* - * SQL92 bit-field data types + * SQL bit-field data types * The following implements BIT() and BIT VARYING(). */ Bit: BitWithLength @@ -10232,7 +10230,7 @@ BitWithoutLength: /* - * SQL92 character data types + * SQL character data types * The following implements CHAR() and VARCHAR(). */ Character: CharacterWithLength @@ -10329,7 +10327,7 @@ opt_charset: ; /* - * SQL92 date/time types + * SQL date/time types */ ConstDatetime: TIMESTAMP '(' Iconst ')' opt_timezone @@ -10661,7 +10659,7 @@ a_expr: c_expr { $$ = $1; } } /* NullTest clause - * Define SQL92-style Null test clause. + * Define SQL-style Null test clause. * Allow two forms described in the standard: * a IS NULL * a IS NOT NULL @@ -11189,7 +11187,7 @@ func_expr: func_name '(' ')' over_clause /* * We consider AGGREGATE(*) to invoke a parameterless * aggregate. This does the right thing for COUNT(*), - * and there are no other aggregates in SQL92 that accept + * and there are no other aggregates in SQL that accept * '*' as parameter. * * The FuncCall node is also marked agg_star = true, @@ -11505,7 +11503,7 @@ func_expr: func_name '(' ')' over_clause } | TRIM '(' BOTH trim_list ')' { - /* various trim expressions are defined in SQL92 + /* various trim expressions are defined in SQL * - thomas 1997-07-19 */ FuncCall *n = makeNode(FuncCall); @@ -12208,7 +12206,7 @@ in_expr: select_with_parens ; /* - * Define SQL92-style case clause. + * Define SQL-style CASE clause. * - Full specification * CASE WHEN a = b THEN c ... ELSE d END * - Implicit argument diff --git a/src/backend/parser/parse_relation.c b/src/backend/parser/parse_relation.c index 82e088a38ba..a01589a1d9c 100644 --- a/src/backend/parser/parse_relation.c +++ b/src/backend/parser/parse_relation.c @@ -70,7 +70,7 @@ static bool isQueryUsingTempRelation_walker(Node *node, void *context); * that (a) has no alias and (b) is for the same relation identified by * schemaname.refname. In this case we convert schemaname.refname to a * relation OID and search by relid, rather than by alias name. This is - * peculiar, but it's what SQL92 says to do. + * peculiar, but it's what SQL says to do. */ RangeTblEntry * refnameRangeTblEntry(ParseState *pstate, @@ -353,7 +353,7 @@ searchRangeTableForRel(ParseState *pstate, RangeVar *relation) * Note: we assume that each given argument does not contain conflicts * itself; we just want to know if the two can be merged together. * - * Per SQL92, two alias-less plain relation RTEs do not conflict even if + * Per SQL, two alias-less plain relation RTEs do not conflict even if * they have the same eref->aliasname (ie, same relation name), if they * are for different relation OIDs (implying they are in different schemas). * @@ -389,7 +389,7 @@ checkNameSpaceConflicts(ParseState *pstate, List *namespace1, if (rte1->rtekind == RTE_RELATION && rte1->alias == NULL && rte2->rtekind == RTE_RELATION && rte2->alias == NULL && rte1->relid != rte2->relid) - continue; /* no conflict per SQL92 rule */ + continue; /* no conflict per SQL rule */ ereport(ERROR, (errcode(ERRCODE_DUPLICATE_ALIAS), errmsg("table name \"%s\" specified more than once", diff --git a/src/backend/parser/parse_utilcmd.c b/src/backend/parser/parse_utilcmd.c index 46dc6724f47..9ad832bbb28 100644 --- a/src/backend/parser/parse_utilcmd.c +++ b/src/backend/parser/parse_utilcmd.c @@ -133,7 +133,7 @@ static void setSchemaName(char *context_schema, char **stmt_schema_name); * will be the transformed CreateStmt, but there may be additional actions * to be done before and after the actual DefineRelation() call. * - * SQL92 allows constraints to be scattered all over, so thumb through + * SQL allows constraints to be scattered all over, so thumb through * the columns and collect all constraints into one place. * If there are any implied indices (e.g. UNIQUE or PRIMARY KEY) * then expand those into multiple IndexStmt blocks. @@ -1405,7 +1405,7 @@ transformIndexConstraints(CreateStmtContext *cxt) /* * Scan the index list and remove any redundant index specifications. This * can happen if, for instance, the user writes UNIQUE PRIMARY KEY. A - * strict reading of SQL92 would suggest raising an error instead, but + * strict reading of SQL 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 @@ -2691,7 +2691,7 @@ transformColumnType(CreateStmtContext *cxt, ColumnDef *column) * that the logic we use for determining forward references is * presently quite incomplete. * - * SQL92 also allows constraints to make forward references, so thumb through + * SQL also allows constraints to make forward references, so thumb through * the table columns and move forward references to a posterior alter-table * command. * |