Re: recent ALTER whatever .. SET SCHEMA refactoring - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: recent ALTER whatever .. SET SCHEMA refactoring
Date
Msg-id 20130114222753.GG5106@alvh.no-ip.org
Whole thread Raw
In response to Re: recent ALTER whatever .. SET SCHEMA refactoring  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: recent ALTER whatever .. SET SCHEMA refactoring
List 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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: s/size_t/off_t/ in sendTimeLineHistory
Next
From: Gurjeet Singh
Date:
Subject: Patches for TODO item: Avoid truncating empty OCDR temp tables on COMMIT