Re: Proposal: OUT parameters for plpgsql - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Proposal: OUT parameters for plpgsql
Date
Msg-id 13998.1111526248@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proposal: OUT parameters for plpgsql  (Pavel Stehule <stehule@kix.fsv.cvut.cz>)
List pgsql-hackers
Pavel Stehule <stehule@kix.fsv.cvut.cz> 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.

Well, what I am after here is basically to try to fix the function
definition style to be more standard.  The SELECT FROM calling style is
admittedly not standard, but it's what we already support and will have
to continue to support indefinitely.  We can go back and work on that
end of things in the future; I don't think this proposal forecloses
anything as far as other call syntaxes go.

> For anonymous out record (not OUT parameters) is better Firebird syntax
>
> CREATE FUNCTION fce (...) RETURNS (c1 integer, c2 integer) AS

That might be more readable, but it's not standard and not flexible
(no INOUT parameters), so I don't really see the advantage.

> When I use OUT params I have to have DECLARE command for variables
> DECLARE b integer;

That's basically what I want to avoid, for the time being at least.
Variables in straight SQL don't make any sense to me: variables go with
conventional, imperative programming languages and SQL really isn't one.
A variable for an OUT result should live in some program that is calling
SQL, which means it's a feature for client-side code or a feature that
exists inside a PL.

The advantage of what I am proposing is basically that we can create
functions that return OUT parameters without having to buy into
inventing SQL variables.  We can always do that later if we decide
we want to.
        regards, tom lane


pgsql-hackers by date:

Previous
From: subhash@nmsu.edu
Date:
Subject: Permissions on tables and views
Next
From: Oleg Bartunov
Date:
Subject: odd problem !