Skip site navigation (1) Skip section navigation (2)

recent ALTER whatever .. SET SCHEMA refactoring

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: recent ALTER whatever .. SET SCHEMA refactoring
Date: 2012-12-20 14:24:46
Message-ID: CA+TgmoZ0+gNf7RDKRc3u5rHXffP=QjqPZKGxb4BsPz65k7qnHQ@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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


Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2012-12-20 14:45:47
Subject: Re: Parser Cruft in gram.y
Previous:From: Robert HaasDate: 2012-12-20 14:11:46
Subject: Re: Parser Cruft in gram.y

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group