From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
Date: Mon, 12 Sep 2016 14:05:33 -0400
Message-ID: <9865.1473703533@sss.pgh.pa.us> (raw)
In-Reply-To: <20160912175811.ids3nlrbgavkom3p@alap3.anarazel.de>
References: <20160523005327.v2tr7obytitxcnna@alap3.anarazel.de>
<20160822214023.aaxz5l4igypowyri@alap3.anarazel.de>
<20160827214829.zo2dfb5jaikii5nw@alap3.anarazel.de>
<5460.1473696601@sss.pgh.pa.us>
<20160912165403.vshr7tazhr6wrpp4@alap3.anarazel.de>
<8136.1473701180@sss.pgh.pa.us>
<20160912174443.w5w55mkmcyfp67w2@alap3.anarazel.de>
<9209.1473702485@sss.pgh.pa.us>
<20160912175811.ids3nlrbgavkom3p@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> On 2016-09-12 13:48:05 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> 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?
> I was kind of envisioning AS VALUE to work for composite types without
> removing their original type (possibly even for TYPEFUNC_SCALAR
> ones).
Maybe. A problem with any of these proposals though is that there's no
place to put a column alias. Yeah, you can stick it on outside the ROWS
FROM, but it seems a bit non-orthogonal to have to do it that way when
you can do it inside the ROWS FROM when adding a coldeflist.
Maybe we could do it like
ROWS FROM (func(...) AS alias)
where the difference from a coldeflist is that there's no parenthesized
list of names/types. It's a bit weird that adding an alias makes for
a semantic not just naming difference, but it's no weirder than these
other ideas.
>> (Although once you look at it that way, it's just a cast spelled in
>> an idiosyncratic fashion.)
> Well, not quite, by virtue of keeping the original type around. After a
> record cast you likely couldn't directly access the columns anymore,
> even if it were a known composite type, right?
Same is true for any of these syntax proposals, no? So far as the rest of
the query is concerned, the function output is going to be an anonymous
record type.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de
Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling)
In-Reply-To: <9865.1473703533@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox