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: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Ash M <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-07 23:55:54
Message-ID: CAKJS1f9t5_Zfc7KVYmpsMjW3BqR_rXv2B3C7i7qukwdh11+yjA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs pgsql-hackers

On Tue, 8 Jan 2019 at 03:54, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> I'm not sure what's a good way to implement this, however. Maybe the
> solution is to have LookupFuncName return InvalidOid when the function
> name is ambiguous and let LookupFuncWithArgs report the error
> appropriately. I think this behavior is weird:
>
> /*
> * When looking for a function or routine, we pass noError through to
> * LookupFuncName and let it make any error messages. Otherwise, we make
> * our own errors for the aggregate and procedure cases.
> */
> oid = LookupFuncName(func->objname, func->args_unspecified ? -1 : argcount, argoids,
> (objtype == OBJECT_FUNCTION || objtype == OBJECT_ROUTINE) ? noError : true);

Why can't we just remove the !noError check in the location where the
error is raised?

I had a look and I can't see any other callers that pass nargs as -1
and can pass noError as true. The only place I see is through
get_object_address() in RemoveObjects(). There's another possible call
in get_object_address_rv(), but there's only 1 call in the entire
source for that function and it passes missing_ok as false.

I ended up with the attached.

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

Attachment Content-Type Size
drop_func_if_not_exists_fix.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bartosz Polnik 2019-01-08 00:08:56 Re: BUG #15577: Query returns different results when executed multiple times
Previous Message Thomas Munro 2019-01-07 23:38:48 Re: BUG #15577: Query returns different results when executed multiple times

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-07 23:56:16 Displaying and dumping of table access methods
Previous Message Tomas Vondra 2019-01-07 23:54:04 Re: valgrind issues on Fedora 28