> > Here, we've somehow got the first two fields of u_address_type - street
> 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...
In response to
pgsql-hackers by date
|Next:||From: Dave Page||Date: 2011-01-25 08:42:21|
|Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers|
|Previous:||From: Heikki Linnakangas||Date: 2011-01-25 07:04:45|
|Subject: Re: Re: patch: fix performance problems with repated decomprimation
of varlena values in plpgsql|
pgsql-jdbc by date
|Next:||From: rsmogura||Date: 2011-01-25 09:06:10|
|Subject: Re: [HACKERS] Fwd: Weird issues when reading UDT from stored
|Previous:||From: Samuel Gendler||Date: 2011-01-21 15:25:39|
|Subject: Re: query for schema existence and create schema in jdbc?|