On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> That's certainly a case that we ought to support somehow. The problem is
>>> staying reasonably consistent with the two-decades-old precedent of the
>>> existing behavior for one target variable.
>
>> My point is that you objected to Pavel's proposal saying "it's not
>> clear whether users want A or B". But I think they always want A.
>
> I'm not sure if that's true or not. I am sure, though, that since
> we've done B for twenty years we can't just summarily change to A.
I agree, but so what? You said that we couldn't adopt Pavel's
proposal for this reason:
===
IIRC, the reason for disallowing that is that it's totally unclear what
the semantics ought to be. Is that variable a single target (demanding
a compatible composite-valued column from the source query), or does it
eat one source column per field within the record/row? The former is 100%
inconsistent with what happens if the record/row is the only INTO target;
while the latter would be very bug-prone, and it's especially unclear what
ought to happen if it's an as-yet-undefined record variable.
===
And I'm saying - that argument is bogus. Regardless of what people
want or what we have historically done in the case where the
record/row is the only INTO target, when there are multiple targets it
seems clear that they want to match up the query's output columns with
the INTO targets 1:1. So let's just do that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers