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 по дате отправления: