Re: BUG #15246: Does not allow an INOUT parameter to receive values when its data type is a user-defined data type.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: BUG #15246: Does not allow an INOUT parameter to receive values when its data type is a user-defined data type.
Дата
Msg-id 12033.1529377583@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: BUG #15246: Does not allow an INOUT parameter to receive valueswhen its data type is a user-defined data type.  ("David G. Johnston" <david.g.johnston@gmail.com>)
Список pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Mon, Jun 18, 2018 at 3:32 PM, PG Bug reporting form <
> noreply@postgresql.org> wrote:
>> p_my_type.rc_tbl1.co_1 := 1; -- ERRO:  "p_my_type.rc_tbl1.co_1" is
>> not
>> variable unknown !!!!

> Short answer is that you cannot simply assign components of a composite
> type one-at-a-time, you have to build up the full final composite result in
> one expression and assign the result of the expression to the typed
> variable (p_my_type in this instance).​

It's not quite that bad.  IIRC, plpgsql handles only one level of field
assignment, so you could write

    p_my_type.rc_tbl1 := ROW(1, 'Teeeeeeeeeeest');

but not

    p_my_type.rc_tbl1.co_1 := 1;

Improving that --- and also allowing mixed array-element-and-field
assignment, say "p_my_type.rc_tbl1[2].co_1 := 1;" --- has been on the
radar screen for a long time, but nobody has gotten round to it.

I think I might've made it a bit easier as of v11, because it'd no longer
be necessary to implement field assignment in two separate code paths
for "rows" and "records".  But it's still a fair amount of work.

            regards, tom lane


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

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: BUG #15245: pg_stat_all_tables does not include partition mastertables
Следующее
От: PG Bug reporting form
Дата:
Сообщение: BUG #15247: At 'ALTER TABLE ADD COLUMN fast default' ,Set attmissingval to NULL in the pg_attribute, query fail