> > > 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...
