Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

Your Concern is valid as well for "IF exists" complaint from users (its a possibility ):
Then I would propose:
1. Either word the return message identical to the drop command message(without the "If Exists") & successfully pass the command.
OR
2. Fail the execution since just using the function name without parameters returns ambiguous results for the Drop to continue.
OR
3. Drop all functions with that function name & successfully pass the command.

With your comment the 1st option looks as a better option.

Regards
Ash

A Marath.

________________________________
From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Sent: Thursday, January 3, 2019 11:45:16 PM
To: makmarath(at)hotmail(dot)com; pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name

On Fri, 4 Jan 2019 at 09:44, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> Operating system: RDS (on Amazon)

You may want to talk to Amazon about this. However, since the same
behaviour exists in PostgreSQL too...

> Run the command : DROP FUNCTION test.func1;
>
> NOTE: This operation failed to execute the drop and reported the following
> message
>
> Message reported by PgAdmin4 & OmniDB:
> ---- start of message ------
> function name "test.func1" is not unique
> HINT: Specify the argument list to select the function
> unambiguously.
> ---- end of message ------

> Run the command : DROP FUNCTION IF EXISTS test.func1;
>
> NOTE: This operation completed successfully without error and reported the
> following message
>
> Message reported by PgAdmin4 & OmniDB:
> ---- start of message ------
> function admq.test1() does not exist, skipping
> ---- end of message ------
> -----------------------------------------------------------------------------------------------------------
> Proposed solution:
> The operation in Step 2 should have failed with the same error as reported
> in Step 1;

It's not really that clear to me that doing that would be any more
correct than the alternative. If we changed the behaviour of this then
someone might equally come along later and complain that they
specified "IF EXISTS" and got an error. Maintaining the status quo at
least has the benefit of not randomly changing the behaviour because
it didn't suit one particular use case. The patch to change the
behaviour is pretty trivial and amounts to removing a single line of
code:

diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index 4661fc4f62..a9912b0986 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -2053,12 +2053,11 @@ LookupFuncName(List *funcname, int nargs,
const Oid *argtypes, bool noError)
{
if (clist->next)
{
- if (!noError)
- ereport(ERROR,
-
(errcode(ERRCODE_AMBIGUOUS_FUNCTION),
-
errmsg("function name \"%s\" is not unique",
-
NameListToString(funcname)),
-
errhint("Specify the argument list to select the function
unambiguously.")));
+ ereport(ERROR,
+
(errcode(ERRCODE_AMBIGUOUS_FUNCTION),
+
errmsg("function name \"%s\" is not unique",
+
NameListToString(funcname)),
+
errhint("Specify the argument list to select the function
unambiguously.")));
}
else
return clist->oid;

I just don't know if we'll have a better database by removing it.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services