Skip site navigation (1) Skip section navigation (2)

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

From: Lukas Eder <lukas(dot)eder(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>, rsmogura <rsmogura(at)softperience(dot)eu>, pgsql-jdbc(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function
Date: 2011-01-25 07:39:51
Message-ID: AANLkTimvqQmkvG0QcruFGGxCrQ63U8srtDtMZBH8WjQU@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
>
> > 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...

In response to

Responses

pgsql-hackers by date

Next:From: Dave PageDate: 2011-01-25 08:42:21
Subject: Re: [HACKERS] Seeking Mentors for Funded Reviewers
Previous:From: Heikki LinnakangasDate: 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: rsmoguraDate: 2011-01-25 09:06:10
Subject: Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function
Previous:From: Samuel GendlerDate: 2011-01-21 15:25:39
Subject: Re: query for schema existence and create schema in jdbc?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group