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

2017-09-19 20:29 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> 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.)
>

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

Regards

Pavel

>
> regards, tom lane
>