Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2016-09-12T17:48:05Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2016-09-12 13:26:20 -0400, Tom Lane wrote: >> Andres Freund <andres@anarazel.de> writes: > On 2016-09-12 12:10:01 -0400, Tom Lane wrote: >>>> I can't say that I like the proposed syntax much. >>> Me neither. But I haven't really found a better approach. It seems >>> kinda consistent to have ROWS FROM (... AS ()) change the picked out >>> columns to 0, and just return the whole thing. >> I just remembered that we allow zero-column composite types, which >> makes this proposal formally ambiguous. So we really need a different >> syntax. I'm not especially in love with the cast-to-record idea, but >> it does dodge that problem. > I kind of like ROWS FROM (... AS VALUE), that seems to confer the > meaning quite well. As VALUE isn't a reserved keyword, that'd afaik only > really work inside ROWS FROM() where AS is required. Hm, wouldn't ... AS RECORD convey the meaning better? (Although once you look at it that way, it's just a cast spelled in an idiosyncratic fashion.) regards, tom lane
Commits
-
Remove obsoleted code relating to targetlist SRF evaluation.
- ea15e18677fc 10.0 landed
-
Doc: improve documentation of new SRF-in-tlist behavior.
- f13a1277aa2d 10.0 landed
-
Move targetlist SRF handling from expression evaluation to new executor node.
- 69f4b9c85f16 10.0 landed
-
Don't split up SRFs when choosing to postpone SELECT output expressions.
- d543170f2fdd 9.6.0 cited