"Kevin O'Gorman" <kogorman@pacbell.net> writes:
> All that being said, I'm not sure enough notice has been taken of one
> aspect of the changes already in place, and likely to become more
> pronounced. It may be okay with everybody, but I don't want it to be
> a big surprise: queries may no longer begin with SELECT, but instead
> with an arbitrary number of left parens.
That's no surprise, because it's been true for a long time. It's
certainly true in the 6.5 grammar, which is the oldest I have on hand.
> In some cases, the semantics gets lost in the syntax. Consider:
> (SELECT * INTO newtable FROM table1) UNION (SELECT * FROM table2);
> Notice the INTO? Doesn't this seem like an odd place for it, in what
> appears to be a subordinate query? Where else would it go? How would
> it grab you in an expression with five or more levels of parens?
> How about five levels of parens and a complicated targetlist before
> you get to the INTO?
Agreed, it's pretty ugly. This one is only partially SQL92's fault,
since it defines SELECT ... INTO for just a limited context:
<select statement: single row> ::= SELECT [ <set quantifier> ] <select list> INTO
<selecttarget list> <table expression>
(<select target list> here appears to mean a list of local variables in
a calling program, a la ECPG, and doesn't really have anything to do
with the table-destination semantics that Postgres puts on the
construct. But I digress.) The above restricted form of SELECT does
not admit UNION/INTERSECT/EXCEPT constructs at the top level. Postgres
has generalized this to allow INTO <target> in a UNION/etc construct,
which means the word SELECT is not necessarily going to be the very
first thing you see. We do require the INTO to be in the leftmost
primitive SELECT, so the only thing you can really see in front of
"SELECT <selectlist> INTO" is some number of left parentheses. To me
the potential hairiness of the <selectlist> seems like a much bigger
readability issue than the leading parens --- but we got that part of
the syntax straight from SQL92.
> What I'm suggesting is that the parens be allowed only on the right
> hand side of the set operations. How does that strike you?
Will not do, first because EXCEPT is not symmetric, and second because
SQL92 does not describe any such limitation.
regards, tom lane