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

Re: recent ALTER whatever .. SET SCHEMA refactoring

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: recent ALTER whatever .. SET SCHEMA refactoring
Date: 2013-01-02 15:48:42
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
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);
> 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;
> 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.

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2013-01-02 15:52:36
Subject: Re: allowing multiple PQclear() calls
Previous:From: Kohei KaiGaiDate: 2013-01-02 15:35:31
Subject: Re: ALTER .. OWNER TO error mislabels schema as other object type

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