Tom,
This will work just great, please go ahead, and I'll adjust the
driver accordingly
Dave
On 21-Jun-05, at 5:49 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
Yeah, I think that might work if I understand it correctly.
Assuming I would be able to prepare, and bind all the
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
Dave Cramer [EMAIL PROTECTED] 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
Dave Cramer [EMAIL PROTECTED] writes:
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
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
Dave Cramer [EMAIL PROTECTED] writes:
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.
This is what I've got in mind:
regression=# create function myfunc(f1 int, f2 int,
I think it makes my code cleaner, I'll give you an update tomorrow
Dave
On 21-Jun-05, at 5:49 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
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
