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
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
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 at
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.
Does
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 message
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
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
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.
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
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, the
People:
OK, found it in SQL99:
SQL parameter declaration ::=
[ parameter mode ] [ SQL parameter name ] parameter type [ RESULT ]
parameter mode ::=
IN
| OUT
| INOUT
... so this is something we need to support, apparently both for Functions and
Procedures (when we get the latter), in the
Pavel Stehule [EMAIL PROTECTED] writes:
On Mon, 21 Mar 2005, Tom Lane wrote:
So typical call style would be
SELECT * FROM foo(1,2,'xyzzy');
I am not sure so this syntax is readable. I'm sure, so this solution is
possible and usefull, but you mix SRF style of calling and normal style.
Awhile back I wrote:
Basically what I am thinking is that we have all the infrastructure
today to solve the OUT-parameter problem, it's just not wrapped up in
an easy-to-use package.
Here is a more fully fleshed-out proposal. The basic goal that I'm
aiming at is to be able to use
Tom Lane [EMAIL PROTECTED] writes:
The generic thing: you can write OUT and INOUT parameters in CREATE
FUNCTION. If you do, you can omit the RETURNS clause, in which case the
result type of the function is implicitly RECORD; or you can specify
RECORD explicitly; or you can specify SETOF
On Mon, Mar 21, 2005 at 02:25:47PM -0500, Tom Lane wrote:
A possible future extension is to add some sort of direct procedure call
syntax in plpgsql. Right now, you'd need to write something like
select into x,y,z from foo(a,b,c);
to call a function with IN parameters a,b,c and get back
Greg Stark [EMAIL PROTECTED] writes:
Do other databases not allow you to specify a return value in addition to the
OUT and INOUT parameters?
Oracle discourages OUT parameters in a function, so PL/SQL at least
shouldn't be a big source of cases where that's a problem.
I would have expected the
On Tue, 21 Mar 2005, Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
The generic thing: you can write OUT and INOUT parameters in CREATE
FUNCTION. If you do, you can omit the RETURNS clause, in which case the
result type of the function is implicitly RECORD; or you can specify
Gavin Sherry [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
(When there is just one, should the default be to return that type
rather than a one-column RECORD?)
ANSI SQL allows at most one OUT parameter for a function (which can be
used instead of having the function return a
ANSI SQL allows at most one OUT parameter for a function (which can be
used instead of having the function return a value via the usual means).
OK, so that answers my question above: a single OUT parameter should be
equated to an ordinary return value, not a RECORD, so as to emulate this
aspect of
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Shouldn't you have the spec in one hand while designing this feature? :D
Actually, plpgsql generally pays more attention to Oracle than the spec ;-)
The truth though is that I'd missed that aspect of SQL99, and now that I
have read it I don't
On Tue, 22 Mar 2005, Christopher Kings-Lynne wrote:
ANSI SQL allows at most one OUT parameter for a function (which can be
used instead of having the function return a value via the usual means).
OK, so that answers my question above: a single OUT parameter should be
equated to an
Gavin Sherry [EMAIL PROTECTED] writes:
I think that not specifying OUT parameters when invoking a function is a
little of confusing but it gives us a lot: its much easier to develop
since we don't have to add a stack of infrastructure for host variables,
for one.
Also, it doesn't stop us from
Tom Lane [EMAIL PROTECTED] writes:
I would have expected the return value to be an extra column added to the
record.
I'd prefer not to do that, because having a return type that's
different from the true return type of the function (ie the RECORD)
is going to cause untold amounts of
On Mon, 21 Mar 2005, Tom Lane wrote:
Awhile back I wrote:
Basically what I am thinking is that we have all the infrastructure
today to solve the OUT-parameter problem, it's just not wrapped up in
an easy-to-use package.
Note that the result type is RECORD; we won't explicitly create a
24 matches
Mail list logo
