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

Re: No error when FROM is missing in subquery

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Thomas H(dot)" <me(at)alternize(dot)com>,"Jaime Casanova" <systemguards(at)gmail(dot)com>,<pgsql-bugs(at)postgresql(dot)org>,"mike" <mike(at)thegodshalls(dot)com>
Subject: Re: No error when FROM is missing in subquery
Date: 2006-12-19 16:28:44
Message-ID: 4587BEDC.EE98.0025.0@wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-bugs
>>> On Tue, Dec 19, 2006 at  9:58 AM, in message
<26199(dot)1166543928(at)sss(dot)pgh(dot)pa(dot)us>,
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote: 
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> I'm having trouble seeing how it is a useful construct in the
context
>> of a scalar subquery.  A non- standard extension should be useful in
some
>> way.
> 
> There is 0 chance that we'd disallow it at the top level after
allowing
> it all these years.
 
I wouldn't want to eliminate it there -- it is clearly a useful
extension to the standard at the top level.
 
> And probably not even just top- level; consider
> 	select 1 union all select 2 union all select 3;
> which has been the recommended workaround up to 8.2 for our lack of
> multi- row VALUES lists.  We will certainly break a lot of code if
we
> disallow that.
 
Point taken.
 
> So now you have to make a case why we should make a
> non- orthogonal distinction between certain subqueries and other
> subqueries.
 
Well, I don't think of the terms for set operations as subqueries, and
there are other differences already in what is allowed for a query term
and a subquery.  Arguably there is more risk of error of the type
recently reported where you are in a scalar subquery context.
 
> As for potential usefulness, consider a set- returning function
invoked
> in the targetlist: it makes perfect sense to do
> 	WHERE foo IN (SELECT mysrf(...))
> and maybe even add an ORDER BY/LIMIT to that.
 
That is sufficient to answer my concerns.  I tend to operate from the
context of the standard, because we have our own ANSI based parser which
generates portable Java query classes.  ORDER BY and LIMIT are not
allowed in the subqueries in the standard but are obviously useful
extensions.  The missing FROM then adds value to the other extensions. 
Case closed.  Thanks.
 
By the way, when I read my previous message it struck me that it could
be taken with a tone I didn't intend.  That was the result of whipping
it out quickly without taking sufficient time to review it.  Sorry; no
offense was intended.  I'll try to avoid doing that again.
 
-Kevin
 


In response to

pgsql-bugs by date

Next:From: sorelDate: 2006-12-19 16:33:35
Subject: BUG #2843: .conf listen_addresses intel 64
Previous:From: Tom LaneDate: 2006-12-19 16:14:27
Subject: Re: BUG #2840: \set HISTCONTROL ignoredups doesn't work in psql

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