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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [HACKERS] Re: issue: record or row variable cannot be part ofmultiple-item INTO list
Дата
Msg-id CAKFQuwaT=-Qkd25_CC-mOUPrKbm8J9kp9Ns2v6q4dBY3=OFLdQ@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] Re: issue: record or row variable cannot be part of multiple-item INTO list  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Sep 19, 2017 at 2:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> Actually, this does work, just not the way one would immediately expect.

On closer inspection, what's actually happening in your example is that
you're getting the SELECT's ct1 result crammed into the first column of
c1, and then a default NULL is stuck into its second column:

> ​ct1: (text, text)​

> DO $$
> SELECT ('1', '2')::ct1 INTO c1;
> RAISE NOTICE '%', c1;
> END;
> $$;

> ​Notice: ("(1,2)",)

Notice the parens/comma positioning.  It's only because text is such
a lax datatype that you didn't notice the problem.


​I saw exactly what you described - that it didn't error out and that the text representation of the single output composite was being stored in the first field of the target composite.  i.e., that it "worked".  Does that fact that it only works if the first field of the composite type is text change your opinion that the behavior is OK to break?

David J.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Show backtrace when tap tests fail
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?