Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function

Lukas Eder <lukas.eder@gmail.com>

From: Lukas Eder <lukas.eder@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Oliver Jowett <oliver@opencloud.com>, rsmogura <rsmogura@softperience.eu>, pgsql-jdbc@postgresql.org, pgsql-hackers@postgresql.org
Date: 2011-01-25T07:39:51Z
Lists: pgsql-hackers
>
> > Here, we've somehow got the first two fields of u_address_type - street
> and

 > zip - squashed together into one column named 'street', and all the other
> > columns nulled out.
>
> I think this is the old problem of PL/pgsql having two forms of SELECT
> INTO.  You can either say:
>
> SELECT col1, col2, col3, ... INTO recordvar FROM ...
>
> Or you can say:
>
> SELECT col1, col2, col3, ... INTO nonrecordvar1, nonrecordvar2,
> nonrecordvar3, ... FROM ...
>
> In this case, since address is a recordvar, it's expecting the first
> form - thus the first select-list item gets matched to the first
> column of the address, rather than to address as a whole.  It's not
> smart enough to consider the types of the items involved - only
> whether they are records.  :-(
>

So what you're suggesting is that the plpgsql code is causing the issues?
Are there any indications about how I could re-write this code? The
important thing for me is to have the aforementioned signature of the
plpgsql function with one UDT OUT parameter. Even if this is a bit awkward
in general, in this case, I don't mind rewriting the plpgsql function
content to create a workaround for this problem...