Re: recent ALTER whatever .. SET SCHEMA refactoring

2012/12/20 Robert Haas <robertmhaas(at)gmail(dot)com>:
> The recent SET SCHEMA refactoring has changed the error message that
> you get when trying to move a function into the schema that already
> contains it.
>
> For a table, as ever, you get:
>
> rhaas=# create table foo (a int);
> CREATE TABLE
> rhaas=# alter table foo set schema public;
> ERROR: table foo is already in schema "public"
>
> Functions used to produce the same message, but not any more:
>
> rhaas=# create function foo(a int) returns int as $$select 1$$ language sql;
> CREATE FUNCTION
> rhaas=# alter function foo(int) set schema public;
> ERROR: function "foo" already exists in schema "public"
>
> The difference is that the first error message is complaining about an
> operation that is a no-op, whereas the second one is complaining about
> a name collision. It seems a bit off in this case because the name
> collision is between the function and itself, not the function and
> some other object with a conflicting name. The root of the problem is
> that AlterObjectNamespace_internal generates both error messages and
> does the checks in the correct order, but for functions,
> AlterFunctionNamespace_oid has a second copy of the conflicting-names
> check that is argument-type aware, which happens before the
> same-schema check in AlterObjectNamespace_internal.
>
> IMHO, we ought to fix this by getting rid of the check in
> AlterFunctionNamespace_oid and adding an appropriate special case for
> functions in AlterObjectNamespace_internal that knows how to do the
> check correctly. It's not a huge deal, but it seems confusing to have
> AlterObjectNamespace_internal know how to do the check correctly in
> some cases but not others.
>
Sorry for my oversight this message.

It seems to me it is a reasonable solution to have a special case for
object types that does not support simple name looking-up with name
itself or combination of name + namespace.
Function and collation are candidates of this special case handling;
here are just two kinds of object.

Another idea is to add a function-pointer as argument of
AlterNamespace_internal for (upcoming) object classes that takes
special handling for detection of name collision.
My personal preference is the later one, rather than hardwired
special case handling.
However, it may be too elaborate to handle just two exceptions.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>