Re: UNNEST with multiple args, and TABLE with multiple funcs

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.

In response to

Responses

Browse pgsql-hackers by date

  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