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

Поиск
Список
Период
Сортировка
От Lukas Eder
Тема Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function
Дата
Msg-id AANLkTimvqQmkvG0QcruFGGxCrQ63U8srtDtMZBH8WjQU@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-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... 

В списке pgsql-jdbc по дате отправления:

Предыдущее
От: rsmogura
Дата:
Сообщение: Re: [HACKERS] Fwd: Weird issues when reading UDT from stored function
Следующее
От: "ml-tb"
Дата:
Сообщение: Double quoted column name from DatabaseMetaData.getIndexInfo