From: | "Kevin O'Gorman" <kogorman(at)pacbell(dot)net> |
---|---|
To: | pgsql-hackers-owner(at)hub(dot)org, pgsql-hackers(at)hub(dot)org |
Subject: | Re: [GENERAL] A rare error |
Date: | 2000-10-27 20:58:57 |
Message-ID: | 39F9EC91.8949274B@pacbell.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin O'Gorman wrote:
>
> pgsql-hackers-owner(at)hub(dot)org wrote:
> >
> > "Kevin O'Gorman" <kogorman(at)pacbell(dot)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(at)pacbell(dot)net
> Permanent e-mail forwarder: mailto:Kevin.O'Gorman(dot)64(at)Alum(dot)Dartmouth(dot)org
> At school: mailto:kogorman(at)cs(dot)ucsb(dot)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(at)pacbell(dot)net
Permanent e-mail forwarder: mailto:Kevin.O'Gorman(dot)64(at)Alum(dot)Dartmouth(dot)org
At school: mailto:kogorman(at)cs(dot)ucsb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-10-27 21:21:38 | Proposal for DROP TABLE rollback mechanism |
Previous Message | Alex Pilosov | 2000-10-27 20:47:18 | Re: Summary: what to do about INET/CIDR |