named parameters in SQL functions
in [PgSql]
|
From: Tom Lane on 15 Nov 2009 20:40 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. (But having said that, an alternate qualification name is something that could be implemented if there were any agreement on what to use.) 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: Andrew Chernow on 15 Nov 2009 21:03 Tom Lane 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. > > (But having said that, an alternate qualification name is something > that could be implemented if there were any agreement on what to use.) Would something like ARG.name be acceptable? -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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 21:09 Andrew Chernow <ac(a)esilo.com> writes: > Tom Lane wrote: >> (But having said that, an alternate qualification name is something >> that could be implemented if there were any agreement on what to use.) > Would something like ARG.name be acceptable? It all depends on how likely you think it is that the function would use a table name or alias matching ARG (or any other proposal). It's certainly true that the function name itself is not immune from conflicts of that sort ... in fact I think we saw a bug report recently from someone who had intentionally chosen a plpgsql function name equal to a table name used in the function :-(. So I'm not wedded to the function name entirely. But it has precedent in plpgsql, and that precedent came from Oracle, so I don't think we should lightly make SQL functions do something different. 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: Andrew Chernow on 15 Nov 2009 21:18 Tom Lane wrote: > Andrew Chernow <ac(a)esilo.com> writes: >> Tom Lane wrote: >>> (But having said that, an alternate qualification name is something >>> that could be implemented if there were any agreement on what to use.) > >> Would something like ARG.name be acceptable? > > It all depends on how likely you think it is that the function would use > a table name or alias matching ARG (or any other proposal). > > It's certainly true that the function name itself is not immune from > conflicts of that sort ... in fact I think we saw a bug report recently > from someone who had intentionally chosen a plpgsql function name equal > to a table name used in the function :-(. So I'm not wedded to the > function name entirely. But it has precedent in plpgsql, and that > precedent came from Oracle, so I don't think we should lightly make SQL > functions do something different. > If the concern is portability, (ANYTHING).name won't work. You would have to stick with function.name or support both styles. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/ -- 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 21:39
Andrew Chernow <ac(a)esilo.com> writes: > Tom Lane wrote: >> It's certainly true that the function name itself is not immune from >> conflicts of that sort ... in fact I think we saw a bug report recently >> from someone who had intentionally chosen a plpgsql function name equal >> to a table name used in the function :-(. So I'm not wedded to the >> function name entirely. But it has precedent in plpgsql, and that >> precedent came from Oracle, so I don't think we should lightly make SQL >> functions do something different. > If the concern is portability, (ANYTHING).name won't work. You would have to > stick with function.name or support both styles. I find the recent SQL drafts pretty darn opaque, but I think that SQL:2008 6.6 <identifier chain> syntax rule 8)b)ii) If N = 2 and PIC1 is equivalent to the <qualified identifier> of a <routine name> RN whose scope contains IC and whose associated <SQL parameter declaration list> includes an SQL parameter SP whose <SQL parameter name> is equivalent to I2, then PIC2 is a candidate basis of IC, the scope of PIC2 is the scope of SP, and the referent of PIC2 is SP. is describing the style "function_name.argument_name". So it's not just Oracle setting that precedent. 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 |