named parameters in SQL functions
in [PgSql]
|
From: Robert Haas on 15 Nov 2009 21:41 On Sun, Nov 15, 2009 at 8:40 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Sun, Nov 15, 2009 at 8:22 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: >>> Well, if the funcname.varname gadget will work, as you suggest elsewhere it >>> could, I think that would suffice. I had assumed that was just something in >>> the plpgsql engine. > >> That gadget isn't horribly convenient for me since my function names >> tend to be 30 or 40 characters long. I wish we had something shorter, >> and maybe constant. But I guess that's a topic for a separate >> (inevitably rejected) patch. > > You're only going to need that if you insist on choosing parameter names > that conflict with columns of the tables the function manipulates. Even > then, attaching column aliases to the tables could be used instead. > I don't see that this is any different from or worse than the extra > typing you'll incur if you insist on using 40-character table names. It's true, but that often seems like a natural thing to do. Someone passes you the ID of a project and you want to look up all the tasks associated with that project and do some computation on them. Well the task table has a project_id column, and that's also the obvious name for the parameter. You can call it pid or my_project_id or v_project_id or any of the other alternatives that are frequently suggested, or just leave it unnamed and refer to it as $1, but to my way of thinking project_id is the most natural choice. > (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? ....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: Andrew Dunstan on 15 Nov 2009 21:52 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. 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:00 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. ....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: Tom Lane on 15 Nov 2009 22:04 Andrew Dunstan <andrew(a)dunslane.net> writes: > Robert Haas wrote: >> 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. All of these are fundamentally illegal syntax, which as was already pointed out up-thread is likely to introduce nasty side-effects of its own. Not to mention being an order of magnitude harder to implement. We have a hook to implement resolving a ColumnRef, ie a qualified identifier. We don't have support for random other things. regards, tom lane -- 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: Tom Lane on 15 Nov 2009 22:05
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? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |