Pavel Stehule <pavel.stehule@gmail.com> writes: > 2017-09-14 12:33 GMT+02:00 Anthony Bykov <a.bykov@postgrespro.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.)
I am not sure if I understand to your objection. This patch do nothing with RECORD variables - where is is impossible or pretty hard to implement any clean solution.
If we do some sophisticated game with multiple RECORD type variables, then probably some positional notations has sense, and in this case we cannot to allow mix scalar and composite values.
so SELECT s,s, C,s,C TO sv, sv, CV, s, RV should be allowed
but
so SELECT s,s, C,s,C TO R, CV, s, RV should be disallowed
