Robert Haas wrote:
On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <and...@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.
If you find plpgsql tiresome, use something else. There are plenty of
alternatives.
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.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
