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
13 matches
Mail list logo
