I think this is the driver's problem. It appears that we are following
the spec, so lets leave this alone.
Regarding what an OUT parameter might mean. We already have some
facility in the FE/BE to indicate the types of the returning columns.
Directionality is implied by where in the bind messa
People:
OK, found it in SQL99:
::=
[ ] [ ] [ RESULT ]
::=
IN
| OUT
| INOUT
... so this is something we need to support, apparently both for Functions and
Procedures (when we get the latter), in the backend, not just JDBC. As you
can imagine, though, SQL03 does nothing to clarify ca
Dave Cramer <[EMAIL PROTECTED]> writes:
> Ok, then I guess the documentation needs to indicate that. Or the
> version I am reading is not up to date.
Oh, you're right, I overlooked adding that to the documentation of
the other statement types that work with function names.
Come to think of it, t
Dave Cramer <[EMAIL PROTECTED]> writes:
> 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.
I think you're thinking at the wrong level. AIUI the issue occurs at
the Parse stage, long before any parameter value is sent (or not
Tom,
> 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.
Where directionality comes in is with OUT-only parameters. Wh
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 an
Ok, then I guess the documentation needs to indicate that. Or the
version I am reading is not up to date.
Dave
Tom Lane wrote:
Dave Cramer <[EMAIL PROTECTED]> writes:
On a related note, drop function needs to support the in/out direction.
It does ... do you see a probl
Dave Cramer <[EMAIL PROTECTED]> 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 mess
H
> It seems to me that the bind message needs to support the notion of
> direction in order for this to work cleanly.
>
> Alternatively we could punt and use SQL Server's mechanism where they
> only support IN, and INOUT, which would require all parameters to be
> sent to the procedure.
Dave Cramer <[EMAIL PROTECTED]> writes:
> On a related note, drop function needs to support the in/out direction.
It does ... do you see a problem?
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists
I've been working on adding the functionality into the jdbc driver and
I'm having some issues.
Currently the bind message does not know anything about directionality
of the parameter. This means that considerable gyrations need to be done
by the driver to transform
create function foo( out p
11 matches
Mail list logo
