Re: ALTER OBJECT any_name SET SCHEMA name - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ALTER OBJECT any_name SET SCHEMA name
Date
Msg-id 5377.1288882268@sss.pgh.pa.us
Whole thread Raw
In response to Re: ALTER OBJECT any_name SET SCHEMA name  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Responses Re: ALTER OBJECT any_name SET SCHEMA name
Re: ALTER OBJECT any_name SET SCHEMA name
List pgsql-hackers
Dimitri Fontaine <dimitri@2ndQuadrant.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 objectColumn 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


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER OBJECT any_name SET SCHEMA name
Next
From: Dimitri Fontaine
Date:
Subject: Re: ALTER OBJECT any_name SET SCHEMA name