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
Re: PROPOSAL FE/BE extension to handle IN/OUT parameters |
Список | 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 по дате отправления: