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
|
Список | 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 SELECTINTO. 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 firstform - thus the first select-list item gets matched to the firstcolumn of the address, rather than to address as a whole. It's notsmart enough to consider the types of the items involved - onlywhether 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 по дате отправления: