Re: [HACKERS] issue: record or row variable cannot be part ofmultiple-item INTO list

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] issue: record or row variable cannot be part ofmultiple-item INTO list
Дата
Msg-id CAKFQuwYhHgU_3dLcaKtqX2VFG-XgcNTRgAJj56OaXfvWYDdr7A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Re: issue: record or row variable cannot be part of multiple-item INTO list  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] issue: record or row variable cannot be part of multiple-item INTO list  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tuesday, September 19, 2017, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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 think it's worth definitively addressing the limitations noted, documenting how they are resolved/handled, and then give the programmer more flexibility while, IMO, marginally increasing complexity.  For me we've programmed the "convenience case" and punted on the technically correct solution.  i.e., we could have chosen to force the user to write select (c1, c2)::ct into vct.

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.

If we change to considering exactly one output column for each target var this seems unnecessary.  Then the one special case is today's single composite column target and multiple output columns.  If there is only one select column it has to be composite.

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: [HACKERS] Re: issue: record or row variable cannot be part ofmultiple-item INTO list
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: [GENERAL] [HACKERS] USER Profiles for PostgreSQL