Re: [GENERAL] A rare error - Mailing list pgsql-hackers
From | Kevin O'Gorman |
---|---|
Subject | Re: [GENERAL] A rare error |
Date | |
Msg-id | 39F9EC91.8949274B@pacbell.net Whole thread Raw |
In response to | Re: [GENERAL] A rare error ("Kevin O'Gorman" <kogorman@pacbell.net>) |
Responses |
Re: Re: [GENERAL] A rare error
|
List | pgsql-hackers |
Kevin O'Gorman wrote: > > pgsql-hackers-owner@hub.org wrote: > > > > "Kevin O'Gorman" <kogorman@pacbell.net> writes: > > Anyway, the bottom line of all this rambling is that if you can get > > rid of the distinction between SelectStmt and select_clause altogether, > > that would be fine with me. You might consider looking at whether you > > can write two nonterminals: a SELECT construct that has no outer parens, > > and then an additional construct > > > > subselect: SelectStmt | '(' subselect ')' > > > > which would be used for all the sub-select nonterminals in SelectStmt > > itself. > > I'm headed in that direction. I've been calling it 'subquery'. > > > > > > OTOH, maybe we don't want NOT IN (((SELECT foo FROM bar))). > > > > If we can't do that then we're still going to get complaints, I think. > > The original bug report in this thread was specifically that the thing > > didn't like redundant parentheses; we should try to remove that > > restriction in all contexts not just some. > > 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. 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? > This just occurred to me: how would you sort the results of this query? The path of least resistance from the way things work now would be most non-obvious: put the ORDER BY on the leftmost query. It looks like this (SELECT * INTO newtable FROM table1 ORDER BY field1) UNION (SELECT * FROM table2); And I have to say that's about the ugliest construct I've seen in a pretty ugly language. > 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? Anyway, that's the direction I'm going in now, but as always, I solicit comments. > > > > > regards, tom lane > > -- > Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net > Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org > At school: mailto:kogorman@cs.ucsb.edu > 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 -- Kevin O'Gorman (805) 650-6274 mailto:kogorman@pacbell.net Permanent e-mail forwarder: mailto:Kevin.O'Gorman.64@Alum.Dartmouth.org At school: mailto:kogorman@cs.ucsb.edu 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
pgsql-hackers by date: