2009/11/16 Robert Haas <robertmh...@gmail.com>: > On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan <and...@dunslane.net> wrote: >> 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. > > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers