Re: [HACKERS] allow referring to functions without arguments when unique - Mailing list pgsql-hackers

On Wed, Mar 1, 2017 at 11:50 AM, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> This is the "grand finale" that goes on top of the "DROP FUNCTION of
> multiple functions" patch set.  The purpose is to allow referring to
> functions without having to spell out the argument list, when the
> function name is unique.  This is especially useful when having to
> operate on "business logic" functions with many many arguments.  It's an
> SQL standard feature, and it applies everywhere a function is referred
> to in the grammar.  We already have the lookup logic for the regproc
> type, and thanks to the grand refactoring of the parser representation
> of functions, this is quite a small patch.  There is a bit of
> reduce/reduce parser mystery, to keep the reviewer entertained.

... Which would be nice.

> (The
> equivalent could be implemented for aggregates and operators, but I
> haven't done that here yet.)

OK. After a lookup, I am just seeing opfamily, opclass missing, so
this patch is doing it as you describe.

I have read through the code once, still I am waiting for the DROP
FUNCTION patches to be committed before doing a real hands-on.

@@ -7198,6 +7198,33 @@ function_with_argtypes:                   n->objargs = extractArgTypes($2);                   $$
=n;               }
 
This may not have arguments listed, so is function_with_argtypes really adapted?

+   /*
+    * If no arguments were specified, the name must yield a unique candidate.
+    */
+   if (nargs == -1 && clist)
+   {
+       if (clist->next)
+           ereport(ERROR,
I would have used list_length here for clarity.

--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -1914,6 +1914,21 @@ LookupFuncName(List *funcname, int nargs, const
Oid *argtypes, bool noError)
The comment at the top of LookupFuncName() needs a refresh. The caller
can as well just use a function name without arguments.
-- 
Michael