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

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
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
Date: 2019-01-04 04:45:16
Message-ID: CAKJS1f9nQyOcCdjJ0HP=DCRanDLOCp7+L2QCnR2BAXM-8Zh5vw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2019-01-04 06:10:05 BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
Previous Message David G. Johnston 2019-01-04 04:06:07 Re: BUG #15573: Need more clarification in Json

Browse pgsql-hackers by date

  From Date Subject
Next Message Kohei KaiGai 2019-01-04 04:46:27 Re: add_partial_path() may remove dominated path but still in use
Previous Message Amit Kapila 2019-01-04 03:54:45 Re: WIP: Avoid creation of the free space map for small tables