Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name - Mailing list pgsql-bugs
From | David Rowley |
---|---|
Subject | Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name |
Date | |
Msg-id | CAKJS1f9nQyOcCdjJ0HP=DCRanDLOCp7+L2QCnR2BAXM-8Zh5vw@mail.gmail.com Whole thread Raw |
In response to | BUG #15572: Misleading message reported by "Drop function operation"on DB with functions having same name (PG Bug reporting form <noreply@postgresql.org>) |
Responses |
BUG #15572: Misleading message reported by "Drop function operation"on DB with functions having same name
Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name |
List | pgsql-bugs |
On Fri, 4 Jan 2019 at 09:44, PG Bug reporting form <noreply@postgresql.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
pgsql-bugs by date: