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 | Resend email |
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 |
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 |
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 |