Re: [HACKERS] Gram.y patches for better parenthesis handling.
Applied. Thanks.
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (select 2) order by foo;
There are a few things that it doesn't do that have been talked
about here at least a little:
1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level. This is not new.
2) It does NOT preserve the odd syntax I found when I started looking
at this, where a SELECT statement could begin with parentheses. Thus,
(SELECT a from foo) order by a;
fails.
I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.
This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti. Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses. In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements. As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might. And I have designs on just such an application.
++ kevin
--
Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED]
Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED]
At school: mailto:[EMAIL PROTECTED]
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html
"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead
--- gram.y.orig Thu Oct 26 13:13:04 2000
+++ gram.yFri Oct 27 17:37:58 2000
@@ -124,14 +124,15 @@
DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt,
DropUserStmt, DropdbStmt, ExplainStmt, ExtendStmt, FetchStmt,
GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt,
- NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt,
+ NotifyStmt, OptimizableStmt, ProcedureStmt
+ QualifiedSelectStmt, ReindexStmt,
RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt, RemoveStmt,
RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty,
RuleStmt, SelectStmt, SetSessionStmt, TransactionStmt, TruncateStmt,
UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt,
VariableSetStmt, VariableShowStmt, ViewStmt
-%type node select_clause, select_subclause
+%type node subquery, simple_select, select_head, set_select
%type list SessionList
%type node SessionClause
@@ -174,19 +175,20 @@
result, OptTempTableName, relation_name_list, OptTableElementList,
OptUnder, OptInherit, definition, opt_distinct,
opt_with, func_args, func_args_list, func_as,
- oper_argtypes, RuleActionList, RuleActionMulti,
+ oper_argtypes, RuleActionList, RuleActionMulti,
+ RuleActionOrSelectMulti, RuleActions, RuleActionBracket,
opt_column_list, columnList, opt_va_list, va_list,
sort_clause, sortby_list, index_params, index_list, name_list,
from_clause, from_list, opt_array_bounds,
expr_list, attrs, target_list, update_target_list,
def_list, opt_indirection, group_clause, TriggerFuncArgs,
- opt_select_limit
+ opt_select_limit, select_limit
%type typnam func_arg, func_return, aggr_argtype
%type boolean opt_arg, TriggerForOpt, TriggerForType, OptTemp
-%type list for_update_clause, update_list
+%type list opt_for_update_clause, for_update_clause, update_list
%type boolean opt_all
%type boolean opt_table
%type boolean opt_chain, opt_trans
@@ -2689,7 +2691,7 @@
RuleStmt: CREATE RULE name AS
{ QueryIsRule=TRUE; }
ON event TO event_object where_clause
-DO opt_instead RuleActionList
+DO opt_instead RuleActions
{
RuleStmt *n = makeNode(RuleStmt);
n-rulename = $3;
@@ -2702,17 +2704,42 @@
}
;
-RuleActionList: NOTHING { $$ = NIL; }
- | SelectStmt{ $$ = makeList1($1); }
- | RuleActionStmt{ $$ = makeList1($1); }
-
Re: [HACKERS] Gram.y patches for better parenthesis handling.
On Sat, 28 Oct 2000, Larry Rosenman wrote:
Err, with Tom's objections, why was this applied?
was going to ask this too ... someone going patch-happy again? :)
* Bruce Momjian [EMAIL PROTECTED] [001028 11:34]:
Applied. Thanks.
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (select 2) order by foo;
There are a few things that it doesn't do that have been talked
about here at least a little:
1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level. This is not new.
2) It does NOT preserve the odd syntax I found when I started looking
at this, where a SELECT statement could begin with parentheses. Thus,
(SELECT a from foo) order by a;
fails.
I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.
This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti. Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses. In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements. As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might. And I have designs on just such an application.
++ kevin
--
Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED]
Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED]
At school: mailto:[EMAIL PROTECTED]
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html
"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead
--- gram.y.orig Thu Oct 26 13:13:04 2000
+++ gram.yFri Oct 27 17:37:58 2000
@@ -124,14 +124,15 @@
DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt,
DropUserStmt, DropdbStmt, ExplainStmt, ExtendStmt, FetchStmt,
GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt,
- NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt,
+ NotifyStmt, OptimizableStmt, ProcedureStmt
+ QualifiedSelectStmt, ReindexStmt,
RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt, RemoveStmt,
RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty,
RuleStmt, SelectStmt, SetSessionStmt, TransactionStmt, TruncateStmt,
UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt,
VariableSetStmt, VariableShowStmt, ViewStmt
-%type node select_clause, select_subclause
+%type node subquery, simple_select, select_head, set_select
%type list SessionList
%type node SessionClause
@@ -174,19 +175,20 @@
result, OptTempTableName, relation_name_list, OptTableElementList,
OptUnder, OptInherit, definition, opt_distinct,
opt_with, func_args, func_args_list, func_as,
- oper_argtypes, RuleActionList, RuleActionMulti,
+ oper_argtypes, RuleActionList, RuleActionMulti,
+ RuleActionOrSelectMulti, RuleActions, RuleActionBracket,
opt_column_list, columnList, opt_va_list, va_list,
sort_clause, sortby_list, index_params, index_list, name_list,
from_clause, from_list, opt_array_bounds,
expr_list, attrs, target_list, update_target_list,
def_list, opt_indirection, group_clause, TriggerFuncArgs,
- opt_select_limit
+ opt_select_limit, select_limit
%type typnam func_arg, func_return, aggr_argtype
%type boolean opt_arg, TriggerForOpt, TriggerForType, OptTemp
-%type list for_update_clause, update_list
+%type list opt_for_update_clause, for_update_clause, update_list
%type boolean opt_all
%type boolean opt_table
%type boolean opt_chain, opt_trans
@@ -2689,7 +2691,7 @@
RuleStmt: CREATE RULE name AS
{ QueryIsRule=TRUE; }
ON event TO event_object where_clause
-DO opt_instead RuleActionList
+DO opt_instead RuleActions
{
RuleStmt *n = makeNode(RuleStmt);
n-rulename = $3;
@@ -2702,17 +2704,42 @@
Re: [HACKERS] Gram.y patches for better parenthesis handling.
Larry Rosenman [EMAIL PROTECTED] writes: Err, with Tom's objections, why was this applied? * Bruce Momjian [EMAIL PROTECTED] [001028 11:34]: Applied. Thanks. Itchy trigger finger today, Bruce? Please revert the change --- I'm still discussing it with Kevin offlist, but I don't feel it's acceptable as-is because it breaks reasonable (non-redundant) UNION/INTERSECT/EXCEPT constructs that have worked for several releases past. Backed out. I applied it because you said "it was not unacceptible", so I thought you liked it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
[HACKERS] Gram.y patches for better parenthesis handling.
Okay, here's my attempt at fixing the problems with parentheses in
subqueries. It passes the normal 'runcheck' tests, and I've tried
a few simple things like
select 1 as foo union (select 2) order by foo;
There are a few things that it doesn't do that have been talked
about here at least a little:
1) It doesn't allow things like "IN(((select 1)))" -- the select
here has to be at the top level. This is not new.
2) It does NOT preserve the odd syntax I found when I started looking
at this, where a SELECT statement could begin with parentheses. Thus,
(SELECT a from foo) order by a;
fails.
I have preserved the ability, used in the regression tests, to
have a single select statement in what appears to be a RuleActionMulti
(but wasn't -- the parens were part of select_clause syntax).
In my version, this is a special form.
This may cause some discussion: I have differentiated the two kinds
of RuleActionMulti. Perhaps nobody knew there were two kinds, because
I don't think the second form appears in the regression tests. This
one uses square brackets instead of parentheses, but originally was
otherwise the same as the one in parentheses. In this version of
gram.y, the square bracket form treats SELECT statements the same
as the other allowed statements. As discussed before on this list,
psql cannot make sense out of the results of such a thing, but an
application might. And I have designs on just such an application.
++ kevin
--
Kevin O'Gorman (805) 650-6274 mailto:[EMAIL PROTECTED]
Permanent e-mail forwarder: mailto:Kevin.O'[EMAIL PROTECTED]
At school: mailto:[EMAIL PROTECTED]
Web: http://www.cs.ucsb.edu/~kogorman/index.html
Web: http://trixie.kosman.via.ayuda.com/~kevin/index.html
"There is a freedom lying beyond circumstance,
derived from the direct intuition that life can
be grounded upon its absorption in what is
changeless amid change"
-- Alfred North Whitehead
--- gram.y.orig Thu Oct 26 13:13:04 2000
+++ gram.y Fri Oct 27 17:37:58 2000
@@ -124,14 +124,15 @@
DropGroupStmt, DropPLangStmt, DropSchemaStmt, DropStmt, DropTrigStmt,
DropUserStmt, DropdbStmt, ExplainStmt, ExtendStmt, FetchStmt,
GrantStmt, IndexStmt, InsertStmt, ListenStmt, LoadStmt, LockStmt,
- NotifyStmt, OptimizableStmt, ProcedureStmt, ReindexStmt,
+ NotifyStmt, OptimizableStmt, ProcedureStmt
+ QualifiedSelectStmt, ReindexStmt,
RemoveAggrStmt, RemoveFuncStmt, RemoveOperStmt, RemoveStmt,
RenameStmt, RevokeStmt, RuleActionStmt, RuleActionStmtOrEmpty,
RuleStmt, SelectStmt, SetSessionStmt, TransactionStmt, TruncateStmt,
UnlistenStmt, UpdateStmt, VacuumStmt, VariableResetStmt,
VariableSetStmt, VariableShowStmt, ViewStmt
-%type node select_clause, select_subclause
+%type node subquery, simple_select, select_head, set_select
%type list SessionList
%type node SessionClause
@@ -174,19 +175,20 @@
result, OptTempTableName, relation_name_list, OptTableElementList,
OptUnder, OptInherit, definition, opt_distinct,
opt_with, func_args, func_args_list, func_as,
- oper_argtypes, RuleActionList, RuleActionMulti,
+ oper_argtypes, RuleActionList, RuleActionMulti,
+ RuleActionOrSelectMulti, RuleActions, RuleActionBracket,
opt_column_list, columnList, opt_va_list, va_list,
sort_clause, sortby_list, index_params, index_list, name_list,
from_clause, from_list, opt_array_bounds,
expr_list, attrs, target_list, update_target_list,
def_list, opt_indirection, group_clause, TriggerFuncArgs,
- opt_select_limit
+ opt_select_limit, select_limit
%type typnam func_arg, func_return, aggr_argtype
%type booleanopt_arg, TriggerForOpt, TriggerForType, OptTemp
-%type list for_update_clause, update_list
+%type list opt_for_update_clause, for_update_clause, update_list
%type booleanopt_all
%type booleanopt_table
%type booleanopt_chain, opt_trans
@@ -2689,7 +2691,7 @@
RuleStmt: CREATE RULE name AS
{ QueryIsRule=TRUE; }
ON event TO event_object where_clause
- DO opt_instead RuleActionList
+ DO opt_instead RuleActions
{
RuleStmt *n = makeNode(RuleStmt);
n-rulename = $3;
@@ -2702,17 +2704,42 @@
}
;
-RuleActionList: NOTHING { $$ = NIL; }
- | SelectStmt{ $$ = makeList1($1); }
- | RuleActionStmt{ $$ = makeList1($1); }
- | '[' RuleActionMulti ']'
Re: [HACKERS] Gram.y patches for better parenthesis handling.
"Kevin O'Gorman" [EMAIL PROTECTED] writes: 2) It does NOT preserve the odd syntax I found when I started looking at this, where a SELECT statement could begin with parentheses. Thus, (SELECT a from foo) order by a; fails. Um, as a general rule that's not an acceptable limitation. Consider (SELECT foo EXCEPT SELECT bar) INTERSECT SELECT baz; Without parens this will mean something quite different, since INTERSECT has higher precedence than EXCEPT. Also, a leading paren is clearly legal according to SQL92 --- trace for example the productions direct select statement: multiple rows query expression non-join query expression non-join query term non-join query primary ::= left paren non-join query expression right paren (UNION/EXCEPT structures are non-join query expression in this hierarchy.) The reason that making this grammar yacc-compatible is so hard is precisely that leading parens must sometimes be part of the SELECT structure, whereas extraneous parens need to be kept out of it. regards, tom lane
