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

2011-02-17 Thread rsmogura
Something like this, Everything must be done on call, due to polymorphic signatures, this can be kept in short living cache, but bear in mind user can alter procedure in meantime. When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how?

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

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 01:14 , Oliver Jowett wrote: 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

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

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path? You may need to pass procedure

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

2011-02-17 Thread Pavel Stehule
2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine procedure oid - how? procedures may have not qualified name. Is any function on backend that will deal with schema search path?

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

2011-02-17 Thread rsmogura
Yes new node should be created and added for 8.x and 9.x releases... On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote: 2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver will detect if procedure call statement is created. 1. Determine

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

2011-02-17 Thread Oliver Jowett
Lukas Eder wrote: 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? Oliver -- Sent via pgsql-hackers mailing list

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

2011-02-17 Thread rsmogura
Maybe change in backend to treat complex types marked in relation as COMPLEX in same way as scalar values is solution, actually I don't know. This can be determined by GUC variable so every one can be happy :) On Thu, 17 Feb 2011 23:08:13 +1300, Oliver Jowett wrote: Lukas Eder wrote: The

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

2011-02-17 Thread Oliver Jowett
Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: 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

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

2011-02-17 Thread Pavel Stehule
2011/2/17 rsmogura rsmog...@softperience.eu: Yes new node should be created and added for 8.x and 9.x releases... what node? Pavel On Thu, 17 Feb 2011 10:53:19 +0100, Pavel Stehule wrote: 2011/2/17 Florian Pflug f...@phlo.org: On Feb17, 2011, at 10:30 , rsmogura wrote: When JDBC driver

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

2011-02-17 Thread rsmogura
Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. On Thu, 17 Feb 2011 23:15:07 +1300, Oliver Jowett wrote: Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: Any suggestions

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

2011-02-17 Thread Oliver Jowett
On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to

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

2011-02-17 Thread rsmogura
On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..? Oliver And it will throw exception

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

2011-02-17 Thread Oliver Jowett
On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types of those), to prevent programming errors. And..?

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

2011-02-17 Thread rsmogura
On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote: On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of resulted parameters (even check types

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

2011-02-17 Thread Oliver Jowett
On 18/02/11 00:52, rsmogura wrote: On Fri, 18 Feb 2011 00:44:07 +1300, Oliver Jowett wrote: On 18/02/11 00:37, rsmogura wrote: On Fri, 18 Feb 2011 00:06:22 +1300, Oliver Jowett wrote: On 17/02/11 23:18, rsmogura wrote: Yes, but driver checks number of declared out parameters and number of

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

2011-02-17 Thread Florian Pflug
On Feb17, 2011, at 11:15 , Oliver Jowett wrote: Florian Pflug wrote: On Feb17, 2011, at 01:14 , Oliver Jowett wrote: 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

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

2011-02-17 Thread Oliver Jowett
On 18/02/11 01:08, Florian Pflug wrote: 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

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

2011-02-17 Thread rsmogura
snip 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 |

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

2011-02-17 Thread Lukas Eder
2011/2/17 Florian Pflug f...@phlo.org On Feb17, 2011, at 01:14 , Oliver Jowett wrote: 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

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

2011-02-17 Thread Lukas Eder
Hi 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 [...] Thanks for insisting! I missed that fact. In the end, it looked like the same error, but you're right about the plpgsql

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

2011-02-16 Thread Lukas Eder
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

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

2011-02-16 Thread Robert Haas
On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder lukas.e...@gmail.com 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

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

2011-02-16 Thread Oliver Jowett
On 17/02/11 00:58, Robert Haas wrote: On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder lukas.e...@gmail.com 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

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

2011-02-16 Thread Robert Haas
On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder lukas.e...@gmail.com wrote: So what should I do? File a bug to the main Postgres mailing list? Or just not support that feature? Well, I thought you just said you'd ruled out a PG bug? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

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

2011-02-16 Thread Robert Haas
On Wed, Feb 16, 2011 at 7:03 AM, Oliver Jowett oli...@opencloud.com wrote: On 17/02/11 00:58, Robert Haas wrote: On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder lukas.e...@gmail.com wrote: I'm not trying to fix the signature. I want exactly that signature. I want to return 1 UDT as an OUT

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

2011-02-16 Thread rsmogura
If I may give some suggestion, I was tried to investigate this, and maybe some this will help When you create procedure with out parameters then return type of this is implicit calculated and may be record or base type (if exactly one out param is defined). In many places I saw comparison of

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

2011-02-16 Thread Oliver Jowett
On 17/02/11 01:10, Robert Haas wrote: 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

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

2011-02-16 Thread Lukas Eder
That was my opinion, but you're saying that JDBC is not the cause either? 2011/2/16 Robert Haas robertmh...@gmail.com On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder lukas.e...@gmail.com wrote: So what should I do? File a bug to the main Postgres mailing list? Or just not support that feature?

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

2011-02-16 Thread Lukas Eder
Hmm, good point. I should try that. I have only tried these syntaxes: connection.prepareStatement(select * from p_enhance_address2()); connection.prepareCall({ call p_enhance_address2(?) }); // with an output parameter registered

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

2011-02-16 Thread Lukas Eder
So what should I do? File a bug to the main Postgres mailing list? Or just not support that feature? 2011/2/16 Oliver Jowett oli...@opencloud.com On 17/02/11 00:58, Robert Haas wrote: On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder lukas.e...@gmail.com wrote: I'm not trying to fix the

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

2011-02-16 Thread Florian Pflug
On Feb16, 2011, at 13:43 , Oliver Jowett wrote: 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

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

2011-02-16 Thread Tom Lane
Florian Pflug f...@phlo.org writes: Hm, I've browsed through the code and it seems that the current behaviour was implemented on purpose. Yes, it's 100% intentional. The idea is to allow function authors to use OUT-parameter notation (in particular, the convention of assigning to a named

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

2011-02-16 Thread Oliver Jowett
On 17/02/11 04:23, Tom Lane wrote: Florian Pflug f...@phlo.org writes: Hm, I've browsed through the code and it seems that the current behaviour was implemented on purpose. Yes, it's 100% intentional. The idea is to allow function authors to use OUT-parameter notation (in particular, the

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

2011-02-15 Thread Robert Haas
On Sat, Feb 12, 2011 at 6:16 AM, Lukas Eder lukas.e...@gmail.com 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

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

2011-02-12 Thread Lukas Eder
I had tried that before. That doesn't seem to change anything. JDBC still expects 6 OUT parameters, instead of just 1... 2011/2/11 Robert Haas robertmh...@gmail.com On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder lukas.e...@gmail.com wrote: So what you're suggesting is that the plpgsql code is

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

2011-02-10 Thread Robert Haas
On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder lukas.e...@gmail.com wrote: 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

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

2011-01-25 Thread rsmogura
Hi, I don't know if this is a bug, but at least I haven't found any clear statement in documentation about; this should be wrote with big and bold letters. In any way I think this is bug or big inconsistency, because of, as was stated in previous mail test=# CREATE FUNCTION

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

2011-01-25 Thread Lukas Eder
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,

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

2011-01-17 Thread Robert Haas
On Mon, Jan 17, 2011 at 12:00 AM, Oliver Jowett oli...@opencloud.com wrote: 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

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

2011-01-16 Thread Robert Haas
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura rsmog...@softperience.eu wrote: Dear hackers :) Could you look at this thread from General. --- I say the backend if you have one row type output result treats it as the full output result, it's really bad if you use STRUCT types (in your example you

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

2011-01-16 Thread Oliver Jowett
On 17/01/11 17:27, Robert Haas wrote: On Wed, Jan 12, 2011 at 5:12 AM, rsmogurarsmog...@softperience.eu wrote: Dear hackers :) Could you look at this thread from General. --- I say the backend if you have one row type output result treats it as the full output result, it's really bad if you

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

2011-01-12 Thread rsmogura
Dear hackers :) Could you look at this thread from General. --- I say the backend if you have one row type output result treats it as the full output result, it's really bad if you use STRUCT types (in your example you see few columns, but this should be one column!). I think backend should