Re: named parameters in SQL functions
От | Pavel Stehule |
---|---|
Тема | Re: named parameters in SQL functions |
Дата | |
Msg-id | 162867790911152046v407aec9fn2c8c9dfc58856636@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: named parameters in SQL functions (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
2009/11/16 Andrew Dunstan <andrew@dunslane.net>: > > > 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. 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
В списке pgsql-hackers по дате отправления: