|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|
|Views:||Raw Message | Whole Thread | Download mbox|
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
|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|
|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|