Re: Commands to change name, schema, owner

Tom Lane writes:

> A few.  Moving a table across schemas would require moving its indexes
> and rowtype as well; conversely you should forbid moving the indexes and
> rowtype by themselves, or altering their owners separately from the
> table, or renaming the rowtype by itself.

Right.  This is mostly solved, so not really "tricky". ;-)

> I am not real sure that renaming a database is safe if there are active
> backends in it; doesn't a backend have its dbname stored statically in a
> few places?

Right, there's a global variable that stores the database name, but that
will have to disappear.  You'll have to look it up in the catalog like
everything else.

> Same goes for renaming a user who has active backends.

That was cleaned up years ago, otherwise the session user/current user
stack would not work.

> (Even if you can fix the instances within the backend, what about
> connected clients, for instance libpq's private state?

That is a good point, but I'm not sure if it's really a problem.  Perhaps
in the first cut, active the active database and the session user may not
be renamed.  Later we can reconsider relaxing that.

> And what if the rename means these clients should not have been allowed
> to connect, per pg_hba.conf?)

I'm not worried about that.  This is much the same as changing your
password: you should not have been allowed to connect because the password
you had entered isn't right anymore.

> Renaming operators would possibly change their precedence, which I don't
> *think* would break rule dumps, but it's something to consider.

I will check that.

> Renaming sequences would break nextval() and related calls on them,
> since we don't have any way to find the references and update the text
> strings.

It sure does, but we already allow renaming of sequences, so this won't be
anything new.

> Changing a function owner might be interesting for SECURITY DEFINER
> functions; I'm not sure what is likely to happen for active or
> already-planned calls on the function.

That will not be a problem, because the user stack is adjusted once before
each call, so the visible owner at the time of the call gets applied.
(What happens inside the function is, of course, anyone's guess.)

> > The command is: ALTER THING oldname RENAME TO newname;
>
> > Requires being the owner of the object (or superuser for group, user,
> > language) and CREATE privilege on containing schema.
>
> The privilege considerations are doubtless different for the several
> kinds of objects that don't live within schemas; could we see a more
> complete spec?

For those objects who don't live within schemas, you only need to own the
object or the containing table, respectively.  No privilege on any schema
is required.  In detail:

constraint -> owner of table
database -> owner of database
rule -> owner of table
schema -> owner of schema
trigger -> owner of table

Some of these call for more involved syntax:

ALTER TABLE name RENAME CONSTRAINT old TO new;
ALTER RULE oldname ON table RENAME TO newname;
ALTER TRIGGER oldname ON table RENAME TO newname;

-- 
Peter Eisentraut   peter_e@gmx.net