1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-14 18:42:34 +03:00

Clean up references to SQL92

In most cases, these were just references to the SQL standard in
general.  In a few cases, a contrast was made between SQL92 and later
standards -- those have been kept unchanged.
This commit is contained in:
Peter Eisentraut
2013-04-20 11:04:41 -04:00
parent 6e481ebff6
commit cc26ea9fe2
25 changed files with 65 additions and 67 deletions

View File

@ -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

View File

@ -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",

View File

@ -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.
*