At this point I'd just like the backend to ignore the OUT parameter if
it were set that way, but allow
it to be sent.
If you consider that a function could have for arguments sake 10
parameters, and they
can be ordered in any fashion; clients have to essentially parse out the
OUT parameters and not send them. So you have an incoming client call
with 10 parameters but some number less than or equal to get sent to the
backend.
At this point I'm leaning towards just using IN, or INOUT params, as
jdbc has a register outparam, and this could be bound to null if were
not explicitly set.
Dave
Tom Lane wrote:
>Dave Cramer <pg@fastcrypt.com> writes:
>
>
>>create function foo( out p1 int, in p2 int, out p3 int) ....
>>then a subsequent
>>
>>
>
>
>
>>"{call = select foo(?,?,?)}
>>
>>
>
>
>
>>This would need to be currently transformed into select foo(?), with the
>>other two being discarded.
>>
>>
>
>
>
>>It seems to me that the bind message needs to support the notion of
>>direction in order for this to work cleanly.
>>
>>
>
>How would it help for BIND to incorporate direction? What would it even
>*mean* for BIND to incorporate direction --- it's a client-to-server
>message, and can hardly be expected to transmit data in the reverse
>direction.
>
> regards, tom lane
>
>
>
>
--
Dave Cramer
http://www.postgresintl.com
519 939 0336
ICQ#14675561