Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] A rare error

From: "Kevin O'Gorman" <kogorman(at)pacbell(dot)net>
To: pgsql-hackers-owner(at)hub(dot)org
Cc: pgsql-hackers(at)hub(dot)org
Subject: Re: [GENERAL] A rare error
Date: 2000-10-27 20:40:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?

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?

>                         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

"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

Next:From: Guy FraserDate: 2000-10-27 20:43:56
Subject: Can't import date using copy
Previous:From: Larry RosenmanDate: 2000-10-27 20:16:36
Subject: Re: Summary: what to do about INET/CIDR

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group