From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PROPOSAL FE/BE extension to handle IN/OUT parameters |
Date: | 2005-06-21 21:24:30 |
Message-ID: | 153F2ED3-C5B4-46F9-B74D-C381E09A3373@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Yeah, I think that might work if I understand it correctly.
Assuming I would be able to prepare, and bind all the parameters, and
the OUT parameters
would be ignored.
FWIW, I proposed adding to the protocol, not modifying the existing
messages, so it would be backward compatible and not break existing
clients.
Dave
On 21-Jun-05, at 5:14 PM, Tom Lane wrote:
> Dave Cramer <pg(at)fastcrypt(dot)com> writes:
>
>> The current situation with IN/OUT parameters requires that
>> considerable juggling is required on the client end to not pass the
>> OUT parameters in the query. This could be alleviated by adding two
>> messages for stored procedure calls
>> 1) PrepareCall which sent the types, and direction of the parameters
>> 2) BindCall which sends the binds the parameters to the above
>>
>
>
>> Is it possible to get this into 8.1, or is this a total non-starter
>>
>
> Changing the protocol is a nonstarter at this late date in the release
> cycle. I previously offered you a hack that would accomplish the same
> thing (or at least it looks like the same thing to me): ignore
> parameters of type VOID when looking up a function. Is that unusable
> from your end?
>
> regards, tom lane
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-06-21 21:26:40 | Re: PROPOSAL FE/BE extension to handle IN/OUT parameters |
Previous Message | Magnus Hagander | 2005-06-21 21:22:54 | pg_terminate_backend idea |