On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
> Robert Haas wrote:
>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew@dunslane.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 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
