From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: UNNEST with multiple args, and TABLE with multiple funcs |
Date: | 2013-11-21 02:51:14 |
Message-ID: | 1385002274983-5779518.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane-2 wrote
> We could conceivably say that we'll implicitly UNNEST() if the function
> returns array, and not otherwise --- but that seems pretty inconsistent
> and surprise-making to me.
The use-cases for putting a scalar array returning function call into a
TABLE construct, and NOT wanting the array to be un-nested, are likely few
and far between.
Neither the inconsistency nor surprise-making are serious deal-breakers for
me.
And if we do go with the "screw the standard" approach then we should just
state right now that we will never adhere to standard on "inconsistency
grounds" and not even encourage others to make it work. If "TABLE(
array_scalar_func() )" ends up only returning a single row then nothing can
be done to make it unnest the array and conform with the syntax without
breaking backward compatibility.
I'd rather change "TABLE" to "FUNCTION" and leave the implementation of
TABLE open for future standards-compliance - which maybe you do as well and
just haven't carried that sentiment to your more recent responses
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/UNNEST-with-multiple-args-and-TABLE-with-multiple-funcs-tp5767280p5779518.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2013-11-21 02:51:31 | Re: Proof of concept: standalone backend with full FE/BE protocol |
Previous Message | Tom Lane | 2013-11-21 02:42:48 | Re: UNNEST with multiple args, and TABLE with multiple funcs |