Re: I believe it will (was Re: Hmm, will this do?)
От | Kevin O'Gorman |
---|---|
Тема | Re: I believe it will (was Re: Hmm, will this do?) |
Дата | |
Msg-id | 00102918030400.01299@trixie.kosman.via.ayuda.com обсуждение исходный текст |
Ответ на | Gram.y patches for better parenthesis handling. ("Kevin O'Gorman" <kogorman@pacbell.net>) |
Ответы |
Re: Re: I believe it will (was Re: Hmm, will this
do?)
(Philip Warner <pjw@rhyme.com.au>)
|
Список | pgsql-hackers |
I've taken another look at this stuff. I think it's a big improvement, but we didn't notice that it does NOT do the thing we set out to. You still cannot say select foo union (((select bar))) and as I think about it, there's no way to allow that without unifying with c_expr. Consider: yacc is a bottom-up parser, with limited look-ahead. So when it sees "(((select bar)" and it has just turned it into "(((SelectStmt)" what is it going to reducenext? It has one char of lookahead, so it can peek out to "(((SelectStmt))" but it still doesn't know what to reduce. It could be that what is wanted is either of "((c_expr)" or "((some_select_type)" and guessing is not allowed.... :-) I have experimented with unifying c_expr and selects, and it is all kinds of messy, because to the parser it appears that you're introducing all sorts of expression tokens into the Select syntax. Of course we would reject all such strings for other reasons, but poor yacc has no way of knowing that. I'm afraid that for now, we should accept the improvements that have been achieved, and consider a more general treatment of parentheses later. What do you think? ++ kevin On Sun, 29 Oct 2000, Kevin O'Gorman wrote: > > That was very helpful. And I was able to eliminate most of the > remaining restrictions by letting a SelectStmt be EITHER > a) a simple_select (which has no top-level parens or qualifiers) > or > b) a select_clause with at least one qualifier. > Option b reintroduces the SORT and LIMIT operations at the > top level, outside parentheses. > > The remaining restriction that is not SQL92 is that a SelectStmt > may not have wholly inclusive parens -- there has to be something > outside of them. If they're really important, one way to do it would > be to say an OptimizableStmt can be a c_expr, and check that it > has a top-level SelectStmt or SetOperationStmt, then treat it as > a Select Statement. > > I also made mods to put the top-level sort,limit and forUpdate in the > top-level node of the tree. In order to make this be workable, I also > modified parsenodes.h so that the structure for SetOperationStmt is a > synonym for SelectStmt, and merged the fields of the two node > types. > > I've attached diffs from the current tip of the tree (as of this morning). > These are still not completely functional until the downstream code > is changed too, of course. > > > On Sat, 28 Oct 2000, you wrote: > > After some more experimentation, I found that gram.y can be modified > > per the attached diffs to yield a conflict-free grammar that allows > > redundant parens and ORDER/LIMIT in subclauses. The remaining > > restrictions are: > > > > * To attach ORDER/LIMIT to a member select of a UNION/INTERSECT/EXCEPT, > > you need to write parens, eg > > (SELECT foo ORDER BY bar) UNION SELECT baz; > > SELECT foo UNION (SELECT bar ORDER BY baz); > > In the second case the parens are clearly necessary to distinguish the > > intent from attaching the ORDER BY to the UNION result. So this seems > > OK to me. > > > > * Parens cannot separate a select clause from its ORDER/LIMIT clauses. > > For example, this is not allowed: > > (SELECT foo FROM table) ORDER BY bar; > > > > The latter restriction is pretty annoying, first because SQL92 says > > it should be legal, and second because we used to accept it. However, > > it might be an acceptable tradeoff for allowing ORDER in subselects. > > Thoughts? > > > > BTW these diffs are just proof-of-concept for the grammar being > > conflict-free; I haven't changed the output structures, so don't > > try to run the code! > > > > 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
В списке pgsql-hackers по дате отправления: