On Wed, Mar 1, 2017 at 11:50 AM, Peter Eisentraut
<peter.eisentr...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
