From: | David Johnston <polobo(at)yahoo(dot)com> |
---|---|
To: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: Update a composite nested type variable |
Date: | 2013-07-08 23:25:12 |
Message-ID: | 1373325912825-5763119.post@n5.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Luca Vernini wrote
> 2013/7/8 David Johnston <
> polobo@
> >
>
>>
>> This may be a pl/pgsql limitation but you should probably provide a
>> complete
>> self-contained example with your attempt so that user-error can be
>> eliminated.
>>
>> David J.
>>
>>
> All right. Here you are a complete example. Just tested it.
> Sorry for the long email.
This does appear to be a limitation. The documentation says pl/pgsql allows
for "simple variables" in the target which 2-layer composite types do not
qualify for.
As a work-around I'd suggest creating local variables for each of the
relevant fields - say by using the same names but with "_" instead of ".";
You will then need to reconstruct each complex value from the basic values
and return the reconstructed value.
r_cus_id := retset.cus_data.id;
r_cus_name := retset.cus_data.name;
r_cus_email := retset.cus_data.email;
r_superpower := retset.superpower:
RETURN SELECT (r_cus_id, r_cus_name, r_cus_email)::type_customer,
r_superpower)::type_supercustomer;
Not tested but as I am writing this I am getting a Deja-Vu sensation which I
think means I am correct and that this somewhat convoluted way is what
you've got.
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Update-a-composite-nested-type-variable-tp5763023p5763119.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
From | Date | Subject | |
---|---|---|---|
Next Message | Campbell, Lance | 2013-07-09 19:25:14 | delete where not in another table |
Previous Message | Luca Vernini | 2013-07-08 19:44:22 | Re: Update a composite nested type variable |