recent ALTER whatever .. SET SCHEMA refactoring

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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company