====================================
CREATE TYPE u_country AS ENUM ('Brazil', 'England', 'Germany')
CREATE TYPE u_street_type AS (
street VARCHAR(100),
no VARCHAR(30)
)
CREATE TYPE u_address_type AS (
street u_street_type,
zip VARCHAR(50),
city VARCHAR(50),
country u_country,
since DATE,
code INTEGER
)
CREATE TABLE t_author (
id INTEGER NOT NULL PRIMARY KEY,
first_name VARCHAR(50),
last_name VARCHAR(50) NOT NULL,
date_of_birth DATE,
year_of_birth INTEGER,
address u_address_type
)
INSERT INTO t_author VALUES (1, 'George', 'Orwell',
TO_DATE('1903-06-25', 'YYYY-MM-DD'), 1903, ROW(ROW('Parliament Hill',
'77'), 'NW31A9', 'Hampstead', 'England', '1980-01-01', null))
INSERT INTO t_author VALUES (2, 'Paulo', 'Coelho',
TO_DATE('1947-08-24', 'YYYY-MM-DD'), 1947, ROW(ROW('Caixa Postal',
'43.003'), null, 'Rio de Janeiro', 'Brazil', '1940-01-01', 2))
CREATE FUNCTION p_enhance_address2 (address OUT u_address_type)
AS $$
BEGIN
SELECT t_author.address
INTO address
FROM t_author
WHERE first_name = 'George';
END;
$$ LANGUAGE plpgsql;
====================================
Now the above works perfectly in postgres. I can also select the UDT
column t_author.address with a SQL SELECT statement directly. But when
I select from the stored function p_enhance_address2 via JDBC, I get a
weird behaviour. I tried these two invocation schemes:
====================================
connection.prepareStatement("select * from p_enhance_address2()");
connection.prepareCall("{ call p_enhance_address2(?) }"); // with an
output parameter registered
====================================
Both calling schemes induce the same behaviour (actually the
CallableStatement is nothing else than selecting from the function).
There seem to be two very distinct problems:
The nested UDT structure completely screws up fetching results. This
is what I get with JDBC:
====================================
PreparedStatement stmt = connection.prepareStatement("select *
from p_enhance_address2()");
ResultSet rs = stmt.executeQuery();
while (rs.next()) {
System.out.println("# of columns: " +
rs.getMetaData().getColumnCount());
System.out.println(rs.getObject(1));
}
====================================
Output:
# of columns: 6
("(""Parliament Hill"",77)",NW31A9)
Why are there 6 columns? And why is the UDT incorrectly fetched (many
fields are missing)
A little improvement can be achieved, when the nested UDT
u_street_type is "flattened" to a varchar, which leads to the
assumption that nested UDT's are poorly supported by the JDBC driver:
====================================
CREATE TYPE u_address_type AS (
street VARCHAR(80),
zip VARCHAR(50),
city VARCHAR(50),
country u_country,
since DATE,
code INTEGER
)
INSERT INTO t_author VALUES (1, 'George', 'Orwell',
TO_DATE('1903-06-25', 'YYYY-MM-DD'), 1903, ROW('Parliament Hill 77',
'NW31A9', 'Hampstead', 'England', '1980-01-01', null))
INSERT INTO t_author VALUES (2, 'Paulo', 'Coelho',
TO_DATE('1947-08-24', 'YYYY-MM-DD'), 1947, ROW('Caixa Postal 43.003',
null, 'Rio de Janeiro', 'Brazil', '1940-01-01', 2))
====================================
Then the results will be something like this:
# of columns: 6
("Parliament Hill 77",NW31A9,Hampstead,England,1980-01-01,)
The UDT record now looks correct (fetched from the result set at
position 1). But there are still 6 columns in the result set.
Some facts:
- I do not experience these problems in pgAdmin III
- I use PostgreSQL 9.0.1, compiled by Visual C++ build 1500, 64-bit
- I use postgresql-9.0-801.jdbc4.jar
Does anyone have any idea what's wrong?
> CREATE TYPE u_street_type AS (
> street VARCHAR(100),
> no VARCHAR(30)
> )
>
> CREATE TYPE u_address_type AS (
> street u_street_type,
> zip VARCHAR(50),
> city VARCHAR(50),
> country u_country,
> since DATE,
> code INTEGER
> )
> ====================================
> Output:
> # of columns: 6
> ("(""Parliament Hill"",77)",NW31A9)
>
> Why are there 6 columns? And why is the UDT incorrectly fetched (many
> fields are missing)
Looks to me like you're getting each field of the UDT as a separate
column. You printed only the first column i.e. the 'street' part.
It might be informative to run with loglevel=2 and see how the server is
returning results. If the driver is reporting 6 columns, that means that
the server is reporting 6 fields in its RowDescription message.
Oliver
--
Sent via pgsql-jdbc mailing list (pgsql...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc
>> ====================================
>> Output:
>> # of columns: 6
>> ("(""Parliament Hill"",77)",NW31A9)
>>
>> Why are there 6 columns? And why is the UDT incorrectly fetched (many
>> fields are missing)
>
> Looks to me like you're getting each field of the UDT as a separate
> column. You printed only the first column i.e. the 'street' part.
Oops, looking closer I see what you mean, that's actually 2 columns of
the surrounding type - street + zip? What are the values of the other 5
columns reported by the driver?
A loglevel=2 trace would still be useful here.
Looks to me like you're getting each field of the UDT as a separate
column. You printed only the first column i.e. the 'street' part.
It might be informative to run with loglevel=2 and see how the server is
returning results. If the driver is reporting 6 columns, that means that
the server is reporting 6 fields in its RowDescription message.
Oops, looking closer I see what you mean, that's actually 2 columns of the surrounding type - street + zip?
What are the values of the other 5 columns reported by the driver?
Result is ok. Because UDT is described in same way as row, it's looks like
that backand do this nasty thing and instead of 1 column, it sends 6 in your
case.
Forward to hackers. Maybe they will say something, because I don;t see this in
docs.
Radek
Lukas Eder <lukas...@gmail.com> Tuesday 11 January 2011 16:55:52
--
Kind regards,
Radek
On Tue, 11 Jan 2011 23:54:19 +0100, Lukas Eder wrote:
> Hmm, you're right, the result seems slightly different. But still the
> UDT record is not completely fetched as if it were selected directly
> from T_AUTHOR in a PreparedStatement...
>
> 2011/1/11 Radosław Smogura
>
>> Lukas Eder Tuesday 11 January 2011 16:55:52
>>
>>> > Looks to me like you're getting each field of the UDT as a
>> separate
>> > > column. You printed only the first column i.e. the 'street'
>> part.
>> >
>> > Exactly, that's what I'm getting
>> >
>> >
>> > It might be informative to run with loglevel=2 and see how the
>> server is
>> >
>> > > returning results. If the driver is reporting 6 columns, that
>> means that
>> > > the server is reporting 6 fields in its RowDescription message.
>> >
>> > Here's what I get (there really is a RowDescription(6)):
>> >
>> > ===================================
>> > 08:15:44.914 (1) PostgreSQL 9.0 JDBC4 (build 801)
>> > 08:15:44.923 (1) Trying to establish a protocol version 3
>> connection to
>> > localhost:5432
>> > 08:15:44.941 (1) FE=> StartupPacket(user=postgres,
>> database=postgres,
>> > client_encoding=UNICODE, DateStyle=ISO, extra_float_digits=2)
>> > 08:15:44.962 (1) 08:15:44.968 (1) FE=>
>> > Password(md5digest=md5ea57d63c7d2afaed5abb3f0bb88ae7b8)
>> > 08:15:44.970 (1) 08:15:44.980 (1) 08:15:44.980 (1)
>> 08:15:44.980 (1) 08:15:44.980 (1) 08:15:44.981 (1)
>> 08:15:44.981 (1) 08:15:44.981 (1) 08:15:44.981 (1)
>> 08:15:44.981 (1) 08:15:44.981 (1) 08:15:44.981 (1)
>> 08:15:44.981 (1) 08:15:44.981 (1) 08:15:44.981 (1)
>> compatible = 9.0
>> > 08:15:44.981 (1) loglevel = 2
>> > 08:15:44.981 (1) prepare threshold = 5
>> > getConnection returning
>> >
>>
>
> driver[className=org.postgresql.Driver,org.postgresql.Driver@77ce3fc5]
>> > 08:15:45,021 DEBUG [org.jooq.impl.StoredProcedureImpl
>> > ] - Executing query : { call public.p_enhance_address2(?) }
>> > 08:15:45.035 (1) simple execute,
>> >
>>
>
> handler=org.postgresql.jdbc2.AbstractJdbc2Statement$StatementResultHandler@
>> > 2eda2cef, maxRows=0, fetchSize=0, flags=17
>> > 08:15:45.036 (1) FE=> Parse(stmt=null,query="select * from
>> > public.p_enhance_address2() as result",oids={2278})
>> > 08:15:45.037 (1) FE=> Bind(stmt=null,portal=null,=)
>> > 08:15:45.038 (1) FE=> Describe(portal=null)
>> > 08:15:45.038 (1) FE=> Execute(portal=null,limit=0)
>> > 08:15:45.038 (1) FE=> Sync
>> > 08:15:45.043 (1) 08:15:45.044 (1) 08:15:45.045 (1)
>> 08:15:45.046 (1) 08:15:45.046 (1) 08:15:45.062 (1)
> Links:
> ------
> [1] mailto:lukas...@gmail.com
> [2] mailto:rsmo...@softperience.eu
I've read this report over a few times now, and I'm still not
understanding exactly what is happening that you're unhappy about.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
If I understand it correctly, the problem is this:
Given the schema and data from the OP
(summary:
t_author is a TABLE
t_author.address is of type u_address_type
u_address_type is a TYPE with fields: street, zip, city, country, since,
code
u_address_type.street is of type u_street_type
u_street_type is a TYPE with fields: street, no)
A bare SELECT works as expected:
> test_udt=# SELECT t_author.address FROM t_author WHERE first_name = 'George';
> address
> -------------------------------------------------------------------
> ("(""Parliament Hill"",77)",NW31A9,Hampstead,England,1980-01-01,)
> (1 row)
However, doing the same via a plpgsql function with an OUT parameter
produces something completely mangled:
> test_udt=# CREATE FUNCTION p_enhance_address2 (address OUT u_address_type) AS $$ BEGIN SELECT t_author.address INTO address FROM t_author WHERE first_name = 'George'; END; $$ LANGUAGE plpgsql;
> CREATE FUNCTION
> test_udt=# SELECT * FROM p_enhance_address2();
> street | zip | city | country | since | code
> -------------------------------------+-----+------+---------+-------+------
> ("(""Parliament Hill"",77)",NW31A9) | | | | |
> (1 row)
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.
Unsurprisingly the JDBC driver produces confusing results when faced
with this, so it was originally reported as a JDBC problem, but the
underlying problem can be seen via psql too.
Oliver
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. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
In any way I think this is bug or big inconsistency, because of, as was
stated in previous mail
test=# CREATE FUNCTION p_enhance_address3 (address OUT u_address_type,
i1 OUT
int)
AS $$
BEGIN
SELECT t_author.address
INTO address
FROM t_author
WHERE first_name = 'George';
i1 = 12;
END;
$$ LANGUAGE plpgsql;
test=# select *
from p_enhance_address3();
address | i1
----------------------------------------------------+----
("(""(""""Parliament Hill"""",77)"",NW31A9)",,,,,) | 12
(1 row),
but if you will create above function without last, i1 parameter
(SELECT * FROM p_enhance_address2();) then result will be
street | zip | city | country | since |
code
-------------------------------------+-----+------+---------+-------+------
("(""Parliament Hill"",77)",NW31A9) | | | | |
In last case, I think, result should be "packed" in one column, because
of it clearly "unpacked" record.
On Tue, 25 Jan 2011 14:39:51 +0700, Lukas Eder wrote:
>>> 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...
Possibly something like address := (SELECT ...) rather than SELECT ...
INTO address?
Oh, hrm. I thought you were trying to fix the return value, rather
than the signature.
I am not sure how to fix the signature. Can you just make it return RECORD?
Oh, OK. Sorry, I can't help you any with the JDBC side...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Well, the underlying problem is that "SELECT * from
function_with_one_out_parameter()" is returning *6* columns, not 1
column. I don't know if that's expected or not on the plpgsql side, but
the JDBC driver has no way of distinguishing that sort of result from a
function that has 6 OUT parameters.
Oliver
If you do SELECT function_with_one_out_parameter() rather than SELECT
* FROM function_with_one_out_parameter(), you'll get just one
argument. Does that help at all?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
In many places I saw comparison of return type to recordoid or complex
type, but check against complex type is through pg_types only, if
typtype is marked 'c'. Unfortunately both rows and STRUCT (complex) has
there 'c' - and this is OK for situation when procedure will return
"table". But for complex types not being recordoid I think additional
check should go. I mean to use get_rel_relkind() and e.g. check if it is
pure complex type.
By the way,
Actually, based on above I saw funny things - I can create table with
column type being other table :) And now If my one output parameter will
be of complex type and relkind row type, what should I get?
On Wed, 16 Feb 2011 09:30:43 +0100, Lukas Eder wrote:
> I'm not trying to fix the signature. I want exactly that signature. I
> want to return 1 UDT as an OUT parameter from a function.
>
> Somewhere between JDBC and the database, this signature is lost, and
> JDBC's internal code tells me that I have to bind 6 OUT parameters,
> instead of 1. It happens to be so, because the UDT contains 6
> attributes, so somehow the JDBC/database protocol flattens the UDT,
> and I think that's a bug, either in JDBC or in the protocol or in the
> database. My findings were that I can correctly read the UDT OUT
> parameter using the pgAdmin III tool, so I excluded the database as a
> bug holder candidate.
>
> Cheers
> Lukas
>
> 2011/2/15 Robert Haas
>
>> On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder wrote:
>> > I had tried that before. That doesn't seem to change anything.
>> JDBC still
>> > expects 6 OUT parameters, instead of just 1...
>>
>> Oh, hrm. I thought you were trying to fix the return value,
>> rather
>> than the signature.
>>
>> I am not sure how to fix the signature. Can you just make it
>> return RECORD?
>>
>> --
>>
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com [2]
>> The Enterprise PostgreSQL Company
>
>
>
> Links:
> ------
> [1] mailto:lukas...@gmail.com
> [2] http://www.enterprisedb.com
> [3] mailto:rober...@gmail.com
> If you do SELECT function_with_one_out_parameter() rather than SELECT
> * FROM function_with_one_out_parameter(), you'll get just one
> argument. Does that help at all?
Unfortunately, not really, because it doesn't work for cases where
there's more than one OUT parameter (if you use the SELECT f() form in
that case, you get one gigantic result column, not one column per OUT
parameter)
I dug into the code and it's actually slightly different to what I
originally described. Currently given a JDBC escape of the form
"{ call f(?,?,?,?) }"
it will rewrite that to:
"SELECT * FROM f($1,$2,$3,$4) AS RESULT"
and this rewriting happens before we know which parameters are bound as
OUT parameters. So we can't special-case the one-OUT-parameter case
without quite a rewrite (no pun intended).
Once we get to the point of query execution, we know which parameters
are OUT parameters, and we bind void parameter values to those (v3
protocol). You have to do a PREPARE/EXECUTE to pass in void parameter
types to get the equivalent via psql, as far as I can tell.
Anyway, it's a bit counterintuitive that
SELECT * FROM f($1,$2) AS RESULT
where f() takes two OUT parameters always returns two columns, but
SELECT * FROM f($1) AS RESULT
might return any number of columns! Is that really the correct behavior
here?
Oliver
Hm, I've browsed through the code and it seems that the current behaviour
was implemented on purpose.
build_function_result_tupdesc_d() in funcapi.c explicitly does
/*
* If there is no output argument, or only one, the function does not
* return tuples.
*/
if (numoutargs < 2)
return NULL;
and examine_parameter_list() in functioncmds.c takes care to set
requiredResultType to RECORDOID only if there is more than one OUT
parameter, otherwise it gets set to the (one) OUT parameter's type.
Might make sense to check the list archives, maybe there is something
there that elucidates the reasoning behind this...
best regards,
Florian Pflug
Any suggestions about how the JDBC driver can express the query to get
the behavior that it wants? Specifically, the driver wants to call a
particular function with N OUT or INOUT parameters (and maybe some other
IN parameters too) and get a resultset with N columns back.
The current approach is to say "SELECT * FROM f(params) AS RESULT" which
works in all cases *except* for the case where there is exactly one OUT
parameter and it has a record/UDT type.
> The result set meta data correctly state that there are 6 OUT columns.
> But only the first 2 are actually fetched (because of a nested UDT)...
The data mangling was just a plpgsql syntactic issue, wasn't it?
Well, the JDBC driver does know how many OUT parameters there are before
execution happens, so it could theoretically do something different for
1 OUT vs. many OUT parameters.
The problem is that currently the translation of the JDBC "{ call }"
escape happens early on, well before we know which parameters are OUT
parameters. Moving that translation later is, at best, tricky, so I was
hoping there was one query form that would handle all cases.
And..?
And it will throw exception when result will income. If you will remove
this then you will lose check against programming errors, when number of
expected parameters is different that number of actual parameters. Bear
in mind that you will get result set of 6 columns, but only 1 is
expected. I think you can't determine what should be returned and how to
fix result without signature.
You've completely missed the point. I am not suggesting we change those
checks at all. I am suggesting we change how the JDBC driver translates
call escapes to queries so that for N OUT parameters, we always get
exactly N result columns, without depending on the datatypes of the
parameters in any way.
Oh god I'm going round and round in circles repeating myself!
There are two problems.
The first problem is a plpgsql problem in that particular function. It's
broken regardless of how you call it. Here's how to fix it:
> testdb=# CREATE FUNCTION p_enhance_address4 (address OUT u_address_type) AS $$ BEGIN address := (SELECT t_author.address FROM t_author WHERE first_name = 'George'); END; $$ LANGUAGE plpgsql;
> CREATE FUNCTION
> testdb=# SELECT * FROM p_enhance_address4();
> street | zip | city | country | since | code
> ------------------------+--------+-----------+---------+------------+------
> ("Parliament Hill",77) | NW31A9 | Hampstead | England | 1980-01-01 |
> (1 row)
The second problem is that the JDBC driver always generates calls in the
"SELECT * FROM ..." form, but this does not work correctly for
one-OUT-parameter-that-is-a-UDT, as seen in the example immediately
above. Here's how to do the call for that particular case:
> testdb=# SELECT p_enhance_address4();
> p_enhance_address4
> -------------------------------------------------------------------
> ("(""Parliament Hill"",77)",NW31A9,Hampstead,England,1980-01-01,)
> (1 row)
The challenge is that the bare SELECT form doesn't work for multiple OUT
parameters, so the driver has to select one form or the other based on
the number of OUT parameters.
Any questions? (I'm sure there will be questions. Sigh.)
Right, I had forgotten that JDBC must be told about OUT parameter with registerOutputType()
> The problem is that currently the translation of the JDBC "{ call }" escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases.
Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either translates to
SELECT * FROM f($1)
or
SELECT * FROM f($1, $2)
depending on whether one of the parameter is OUT. Without knowing the number of output parameters, how do you distinguish these two cases?
best regards,
Florian Pflug
>> Well, the JDBC driver does know how many OUT parameters there are before execution happens, so it could theoretically do something different for 1 OUT vs. many OUT parameters.
>
> Right, I had forgotten that JDBC must be told about OUT parameter with registerOutputType()
>
>> The problem is that currently the translation of the JDBC "{ call }" escape happens early on, well before we know which parameters are OUT parameters. Moving that translation later is, at best, tricky, so I was hoping there was one query form that would handle all cases.
>
> Hm, now I'm confused. Even leaving the single-OUT-parameter problem aside, the JDBC statement {call f(?,?)} either translates to
> SELECT * FROM f($1)
> or
> SELECT * FROM f($1, $2)
> depending on whether one of the parameter is OUT. Without knowing the number of output parameters, how do you distinguish these two cases?
Currently it always includes *all* parameters in the call, regardless of
the number of OUT parameters (as mentioned, it doesn't even know how
many OUT parameters there are at that point). As we discover OUT
parameters, we bind void types to them, and the server does the rest of
the heavy lifting. Something roughly equivalent to this:
> testdb=# PREPARE s1(void) AS SELECT * FROM p_enhance_address4($1); -- function has no IN parameters, one OUT parameter
> PREPARE
> testdb=# EXECUTE s1(null);
> street | zip | city | country | since | code
> ------------------------+--------+-----------+---------+------------+------
> ("Parliament Hill",77) | NW31A9 | Hampstead | England | 1980-01-01 |
> (1 row)
Oliver
There are two problems.
The first problem is a plpgsql problem in that particular function. It's
broken regardless of how you call it. Here's how to fix it [...]
The second problem is that the JDBC driver always generates calls in the
"SELECT * FROM ..." form, but this does not work correctly for
one-OUT-parameter-that-is-a-UDT, as seen in the example immediately
above. Here's how to do the call for that particular case [...]
Any questions? (I'm sure there will be questions. Sigh.)