Re: [GENERAL] A rare error

Поиск
Список
Период
Сортировка
От Kevin O'Gorman
Тема Re: [GENERAL] A rare error
Дата
Msg-id 39F9EC91.8949274B@pacbell.net
обсуждение исходный текст
Ответ на Re: [GENERAL] A rare error  ("Kevin O'Gorman" <kogorman@pacbell.net>)
Ответы Re: Re: [GENERAL] A rare error  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Kevin O'Gorman"
Дата:
Сообщение: Gram.y patches for better parenthesis handling.
Следующее
От: "Kevin O'Gorman"
Дата:
Сообщение: Problem with installing as root