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 plpgs
2011/2/17 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 othe
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
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
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
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
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 o
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.
>>
>
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 when
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
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
2011/2/17 rsmogura :
> 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 :
>>>
>>> On Feb17, 2011, at 10:30 , rsmogura wrote:
When JDBC driver will detect if p
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
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 resu
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 (pgsql-hackers@postgr
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 :
On Feb17, 2011, at 10:30 , rsmogura wrote:
When JDBC driver will detect if procedure call statement is
created.
1. Determine procedure oid - h
2011/2/17 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
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 param
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 r
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? procedures
On 17/02/11 04:23, Tom Lane wrote:
> Florian Pflug 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 conven
Florian Pflug 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 variable to set
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 c
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
> On 17/02/11 00:58, Robert Haas wrote:
> > On Wed, Feb 16, 2011 at 3:30 AM, Lukas Eder
> wrote:
> >> I'm not trying to fix the signature. I want exactly that signature.
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
===
That was my opinion, but you're saying that JDBC is not the cause either?
2011/2/16 Robert Haas
> On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder 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 y
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 on
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
On Wed, Feb 16, 2011 at 7:03 AM, Oliver Jowett wrote:
> On 17/02/11 00:58, Robert Haas wrote:
>> On Wed, Feb 16, 2011 at 3:30 AM, 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.
>>>
>>> Somew
On Wed, Feb 16, 2011 at 7:07 AM, Lukas Eder 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 Enterprise PostgreSQL
On 17/02/11 00:58, Robert Haas wrote:
> On Wed, Feb 16, 2011 at 3:30 AM, 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, an
On Wed, Feb 16, 2011 at 3:30 AM, 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 hav
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
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 sig
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
> On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder wrote:
> > So what you're suggesting is that the plpgsql code is causing the issues?
> > Are there any ind
On Tue, Jan 25, 2011 at 2:39 AM, Lukas Eder 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 function with one U
>
> > 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:
>
> SELEC
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 p_enhance_address3
On Mon, Jan 17, 2011 at 12:00 AM, Oliver Jowett 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 t_author.address INTO address
On 17/01/11 17:27, Robert Haas wrote:
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura 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
On Wed, Jan 12, 2011 at 5:12 AM, rsmogura 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 see few columns, b
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 r
42 matches
Mail list logo
