Re: named parameters in SQL functions

2009/11/16 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>> Robert Haas wrote:
>>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(at)dunslane(dot)net>
>>> wrote:
>>>> Robert Haas wrote:
>>>>>> (But having said that, an alternate qualification name is something
>>>>>> that could be implemented if there were any agreement on what to use.)
>>>>>
>>>>> Well that is the tricky part, for sure.  I would personally prefer
>>>>> something like ${name} rather than a prefix, but I think you're likely
>>>>> to veto that outright.  So, anything reasonably short would be an
>>>>> improvement over the status quo.  self?  this?  my?
>>>>
>>>> I think it would have to be a reserved word. The obvious existing keyword
>>>> to
>>>> use is "function" but unless I'm mistaken we'd need to move it from
>>>> unreserved keyword to reserved, and I'm not sure this would justify that.
>>>
>>> I don't see why it would need to be a reserved word.  We're not
>>> changing how it gets parsed, just what it means.  At any rate
>>> "FUNCTION." is a 9-character prefix, which is rather longer than I
>>> would prefer.  PL/pgsql is a tiresomely long-winded language in
>>> general, IMHO, although some of Tom's changes for 8.5 will help with
>>> that.
>>
>> Umm, what has this to do with plpgsql? We're talking about what to use in
>> pure SQL functions.
>
> I assume that we might consider implementing the same thing in both
> languages, if we get consensus on what it is.  Perhaps I'm all wet.
>
>> If you find plpgsql tiresome, use something else. There are plenty of
>> alternatives.
>
> Actually, I find PL/pgsql to be awesome.  The only thing I find
> tiresome about it is that is quite longwinded.  But it at least has
> the advantage that you can embed SQL queries directly into it, without
> having to wrap yet another layer of quoting around them, so for the
> sorts of things I typically do it tends to be better than any of the
> alternatives with which I'm familiar.  RETURN QUERY is a big step in
> the right direction (avoiding the need to write FOR x IN <query> LOOP
> RETURN NEXT x END LOOP). Tom's changes to enable short-circuit IF
> evaluation should improve this quite a bit, too.  But anything else we
> can do is all to the good as far as I'm concerned.

I inclined to return back to plpgpsm reimplementation. PSM should have
very short and clean code.

CREATE OR REPLACE FUNCTION srffunc(param) RETURNS TABLE(param) AS
$$
RETURN SELECT * FROM foo;
$$ LANGUAGE plpgpsm;

This one return statement function should be little bit better
optimalised then plpgsql (from srf view).

Pavel

>
>> I think the debate is likely to be pointless in any case - it seems clear
>> that there are objections to anything other than funcname.paramname as a
>> disambiguating mechanism, so let's just go with that. It will still be a
>> considerable advance.
>
> OK, onto the next windmill.
>
> ...Robert
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>