named parameters in SQL functions
in [PgSql]
|
From: Andrew Dunstan on 15 Nov 2009 22:14 Robert Haas wrote: > On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 Nov 2009 22:23 On Sun, Nov 15, 2009 at 10:05 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> 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. > > This from the guy who likes 40-character function names? Hrm... I think this is bikeshedding at its finest - but having said that, thinking about what I usually do a little more, my PL/pgsql functions tend to be either triggers, which tend to have names like tablename_postupdate() [so around 20 characters, depending on the length of the table name] or else they tend to be functions that update some sort of summary statistics... like, oh, say, updating the task table with the total amount of time worked on each task by aggregating over a time log table. Those functions tend to get a name like update_task_time_worked(). That's only 23, but task is a pretty short word, so some of them might be a bit longer than that. So maybe 40 is an overestimate, although I probably do have a few that are close to that long. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 15 Nov 2009 22:33 On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > Robert Haas wrote: >> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 15 Nov 2009 23:46 2009/11/16 Andrew Dunstan <andrew(a)dunslane.net>: > > > Robert Haas wrote: >> >> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(a)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. we should to use some like #option from plpgsql too. create or replace function verylongname(p1 integer) returns int as $$ #option paramalias v SELECT ... WHERE x = v.p1 Pavel >> >> >> > > 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(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 15 Nov 2009 23:51
2009/11/16 Robert Haas <robertmhaas(a)gmail.com>: > On Sun, Nov 15, 2009 at 10:14 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> Robert Haas wrote: >>> On Sun, Nov 15, 2009 at 9:52 PM, Andrew Dunstan <andrew(a)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(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |