Re: recent ALTER whatever .. SET SCHEMA refactoring
От | Alvaro Herrera |
---|---|
Тема | Re: recent ALTER whatever .. SET SCHEMA refactoring |
Дата | |
Msg-id | 20130114222753.GG5106@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: recent ALTER whatever .. SET SCHEMA refactoring (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: recent ALTER whatever .. SET SCHEMA refactoring
|
Список | pgsql-hackers |
Kohei KaiGai escribió: > I'm probably saying same idea. It just adds invocation of external > functions to check naming conflicts of functions or collation; that > takes additional 4-lines for special case handling > in AlterObjectNamespace_internal(). Okay, I can agree with this implementation plan. I didn't like your patch very much though; I'm not sure that the handling of collations was sane. And the names of the AlterFooNamespace_oid() functions is now completely misleading, because they no longer do that. So I renamed them, and while at it I noticed that the collation case can share code with the RENAME code path; the function case could probably do likewise, but it becomes uglier. Note that after this patch, the error message now cites the function signature, not just the name. This is more consistent with other cases. 9.2 and HEAD: alvherre=# alter function foo.f(int,int) set schema bar; ERROR: function "f" already exists in schema "bar" (this error is misleading, because there can validly be a f(int) function in schema bar and that wouldn't cause a problem for this SET SCHEMA command). After my patch: alvherre=# alter function foo.f(int,int) set schema bar; ERROR: function f(integer, integer) already exists in schema "bar" -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: