From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | anderson(dot)ant(dot)oli(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15246: Does not allow an INOUT parameter to receive values when its data type is a user-defined data type. |
Date: | 2018-06-19 03:06:23 |
Message-ID: | 12033.1529377583@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Mon, Jun 18, 2018 at 3:32 PM, PG Bug reporting form <
> noreply(at)postgresql(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2018-06-19 04:19:55 | BUG #15247: At 'ALTER TABLE ADD COLUMN fast default' , Set attmissingval to NULL in the pg_attribute, query fail |
Previous Message | Amit Langote | 2018-06-19 01:49:17 | Re: BUG #15245: pg_stat_all_tables does not include partition master tables |