"Kevin Grittner" <Kevin.Grittner@wicourts.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. 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. So now you have to make a case why we should make a
non-orthogonal distinction between certain subqueries and other
subqueries.
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. Yeah, no doubt this is
easy to change to putting the SRF in FROM, but you can bet there are
Postgres applications out there today using it; we have never officially
deprecated this way of using an SRF.
I also recall having advised people in years past to use dummy
(SELECT expr) sub-selects to work around planning issues. I don't
recall at the moment whether any of those issues are still live, but
again you can bet the construct is still in some applications' SQL.
So basically we get to introduce some arbitrary non-orthogonality, plus
break an unknown number of applications, in order to block off a type
of user error that AFAIR has never been complained of before in all the
years I've been working with Postgres. Sorry, no sale ...
regards, tom lane
