On Mon, Oct 2, 2017 at 12:28 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Sep 19, 2017 at 3:18 PM, Tom Lane <t...@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
