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 styl
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
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 amo
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
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
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
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
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 functi
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 spec
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
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 b
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
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 OUT-parame
13 matches
Mail list logo
