Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Well, I'll go fix as you say, putting the check back into the
> callers. That won't help a bit with the code duplication feeling we have
> when reading the patch, though. Any idea on this front?

Not having read the patch, but ... the idea that was in the back of
my mind was to have a generic AlterObjectNamespace function that
would take parameters approximately like the following:

	OID of catalog containing object
	Column number of catalog's namespace column (Anum_xxx constant)
	OID of intended new namespace

You could do a generic heap_open() on the catalog using the OID,
and then use heap_modify_tuple to apply the namespace column update.

It might be nice to include the "object already exists" check here
too, which could probably be done if in addition the column number
of the name column were passed in.  Permission checks too, if the
owner column number were passed in.  Etc.

Obviously this doesn't work for tables, but they're sufficiently
complex beasts that it's not unusual for them to need a different
code path.  Doesn't help for functions/operators either, since their
collision check isn't just name and namespace.  But that's OK IMO.
I'd be happy if we could unify the code paths for objects that have a
single catalog entry to update and a simple name/namespace collision
check to make.

			regards, tom lane

In response to

• Re: ALTER OBJECT any_name SET SCHEMA name at 2010-11-04 14:37:37 from Dimitri Fontaine

Responses

• Re: ALTER OBJECT any_name SET SCHEMA name at 2010-11-04 15:16:17 from Dimitri Fontaine
• Re: ALTER OBJECT any_name SET SCHEMA name at 2010-11-04 19:39:31 from Dimitri Fontaine

pgsql-hackers by date

Next:	From: Dimitri Fontaine	Date: 2010-11-04 14:52:53
	Subject: Re: ALTER OBJECT any_name SET SCHEMA name
Previous:	From: Alvaro Herrera	Date: 2010-11-04 14:39:18
	Subject: Re: ALTER OBJECT any_name SET SCHEMA name