Re: [GENERAL] A rare error

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

In response to

Responses

Browse pgsql-hackers by date

  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