1111 *
1212 *
1313 * IDENTIFICATION
14- * $Header: /cvsroot/pgsql/src/backend/parser/gram.y,v 2.216 2001/01/17 17:26:45 momjian Exp $
14+ * $Header: /cvsroot/pgsql/src/backend/parser/gram.y,v 2.217 2001/01/20 17:37:52 tgl Exp $
1515 *
1616 * HISTORY
1717 * AUTHORDATEMAJOR EVENT
@@ -3604,10 +3604,6 @@ from_list: from_list ',' table_ref{ $$ = lappend($1, $3); }
36043604 * between table_ref := '(' joined_table ')' alias_clause
36053605 * and joined_table := '(' joined_table ')'. So, we must have the
36063606 * redundant-looking productions here instead.
3607- *
3608- * Note that the SQL spec does not permit a subselect (<derived_table>)
3609- * without an alias clause, so we don't either. This avoids the problem
3610- * of needing to invent a refname for an unlabeled subselect.
36113607*/
36123608table_ref :relation_expr
36133609{
@@ -3618,6 +3614,23 @@ table_ref: relation_expr
36183614$1 ->name =$2 ;
36193615$$ = (Node *)$1 ;
36203616}
3617+ | select_with_parens
3618+ {
3619+ /*
3620+ * The SQL spec does not permit a subselect
3621+ * (<derived_table>) without an alias clause,
3622+ * so we don't either. This avoids the problem
3623+ * of needing to invent a unique refname for it.
3624+ * That could be surmounted if there's sufficient
3625+ * popular demand, but for now let's just implement
3626+ * the spec and see if anyone complains.
3627+ * However, it does seem like a good idea to emit
3628+ * an error message that's better than "parse error".
3629+ */
3630+ elog (ERROR," sub-SELECT in FROM must have an alias"
3631+ " \n\t For example, FROM (SELECT ...) [AS] foo"
3632+ $$ =NULL ;
3633+ }
36213634| select_with_parens alias_clause
36223635{
36233636RangeSubselect *n = makeNode(RangeSubselect);