On Sat, May 13, 2017 at 4:20 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
Maybe I'm just confused here, but do you think that anyone at all wants the second behavior? I think the fact that single-target INTO lists and multiple-target INTO lists are handled completely differently is extremely poor language design. It would have been far better, as you suggested downthread, to have added some syntax up front to let people select the behavior that they want, but I think there's little hope of changing this now without creating even more pain. I have a really hard time, however, imagining that anyone writes SELECT a, b, c, d, e, f, g, h, i, j, k INTO x, y, z and wants some of a-k to go into x, some more to go into y, and some more to go into z (and heaven help you if you drop a column from x or y -- now the whole semantics of the query change, yikes). What's reasonable is to write SELECT a, b, c INTO x, y, z and have those correspond 1:1. -- 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
