Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name
От | Alvaro Herrera |
---|---|
Тема | Re: BUG #15572: Misleading message reported by "Drop functionoperation" on DB with functions having same name |
Дата | |
Msg-id | 201901071454.wxkoyoq4s5qp@alvherre.pgsql обсуждение исходный текст |
Ответ на | 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 |
On 2019-Jan-04, David Rowley wrote: > It's not really that clear to me that doing that would be any more > correct than the alternative. I think it would be. Specifying a function without params works only if it's unambiguous; if ambiguity is possible, raise an error. On the other hand, lack of IF EXISTS is supposed to raise an error if the function doesn't exist; its presence means not the report that particular error, but it doesn't mean to suppress other errors such as the ambiguity one. 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); -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-bugs по дате отправления: