Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name
От | Tom Lane |
---|---|
Тема | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name |
Дата | |
Msg-id | 28204.1550694999@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name
|
Список | pgsql-bugs |
David Rowley <david.rowley@2ndquadrant.com> writes: > On Wed, 20 Feb 2019 at 18:56, Michael Paquier <michael@paquier.xyz> wrote: >> I think that the right call is to add the object type into the >> arguments of LookupFuncName(). I'm not clear how that helps exactly? > But there are plenty of callers that use LookupFuncName() directly. Do > you happen to know it's okay for all those to error out with the > additional error conditions that such a change would move into that > function? I certainly don't know that. The real problem here is that you've unilaterally decided that all callers of get_object_address() need a particular behavior --- and not only that, but a behavior that seems fairly surprising and unprincipled, given that get_object_address's option is documented as "missing_ok" (something the patch doesn't even bother to change). It's not very apparent to me why function-related lookups should start behaving differently from other lookups in that function, and it's sure not apparent that all callers of get_object_address() are on board with it. Should we be propagating that 3-way flag further up, to get_object_address() callers? I dunno. regards, tom lane
В списке pgsql-bugs по дате отправления: