Re: PROPOSAL FE/BE extension to handle IN/OUT parameters

Поиск
Список
Период
Сортировка
От Dave Cramer
Тема Re: PROPOSAL FE/BE extension to handle IN/OUT parameters
Дата
Msg-id 153F2ED3-C5B4-46F9-B74D-C381E09A3373@fastcrypt.com
обсуждение исходный текст
Ответ на Re: PROPOSAL FE/BE extension to handle IN/OUT parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PROPOSAL FE/BE extension to handle IN/OUT parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PROPOSAL FE/BE extension to handle IN/OUT parameters  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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@fastcrypt.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
>
>



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: pg_terminate_backend idea
Следующее
От: Tom Lane
Дата:
Сообщение: Re: PROPOSAL FE/BE extension to handle IN/OUT parameters