Re: Re: issue: record or row variable cannot be part of multiple-item INTO list

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> 2017-09-14 12:33 GMT+02:00 Anthony Bykov <a(dot)bykov(at)postgrespro(dot)ru>:
>> As far as I understand, this patch adds functionality (correct me if I'm
>> wrong) for users. Shouldn't there be any changes in doc/src/sgml/ with the
>> description of new functionality?

> It removes undocumented limit. I recheck plpgsql documentation and there
> are not any rows about prohibited combinations of data types.

I remain of the opinion that this patch is a fundamentally bad idea.
It creates an inconsistency between what happens if the INTO target list
is a single record/row variable (it absorbs all the columns of the query
output) and what happens if a record/row variable is part of a
multi-variable target list (now it just absorbs one column, which had
better be composite). That's going to confuse people, especially since
you haven't documented it. But even with documentation, it doesn't seem
like good design. Aside from being inconsistent, it doesn't cover all
the cases --- what if you have just one query output column, that is
composite, and you'd like it to go into a composite variable? That
doesn't work today, and this patch doesn't fix it, but it does create
enough confusion that we never would be able to fix it.

I'd be much happier if there were some notational difference
between I-want-the-composite-variable-to-absorb-a-composite-column
and I-want-the-composite-variable-to-absorb-N-scalar-columns.
For backwards compatibility with what happens now, the latter would
have to be the default. I'm wondering about "var.*" or "(var)" as
the notation signaling that you want the former, though neither of
those seem like they're very intuitive.

If we had a notation like that, it'd be possible to ask for either
behavior within a larger target list, except that we'd still need
to say that I-want-a-RECORD-variable-to-absorb-N-scalar-columns
has to be the only thing in its target list. Otherwise it's not
very clear what N ought to be. (In some cases maybe you could
reverse-engineer N from context, but I think that'd be overly
complicated and bug prone.)

regards, tom lane