Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name
| От | David Rowley |
|---|---|
| Тема | Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name |
| Дата | |
| Msg-id | CAKJS1f-2-wVsN5zXaKWdp4xOUkkstnoPo0Lis6RQ=AEo3_pcig@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: BUG #15572: Misleading message reported by "Drop function operation" on DB with functions having same name (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
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 |
| Список | pgsql-bugs |
On Wed, 9 Jan 2019 at 13:36, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > David Rowley <david.rowley@2ndquadrant.com> writes: > > Why can't we just remove the !noError check in the location where the > > error is raised? > > I don't like that a bit --- the point of noError is to prevent throwing > errors, and it doesn't seem like it should be LookupFuncName's business > to decide it's smarter than its callers. Maybe we need another flag > argument? Well, I guess you didn't have backpatching this in mind. The reason I thought it was okay to hijack that flag was that the ambiguous error was only raised when the function parameters were not defined. I chased around and came to the conclusion this only happened during DROP. Maybe that's a big assumption as it certainly might not help future callers passing nargs as -1. I've attached another version with a newly added flag. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-bugs по дате отправления: