Re: Upgrading to 8.2, changes in user/group management scripts

On Fri, Jan 19, 2007 at 03:45:18PM -0600, Peter Koczan wrote:
> I'm upgrading our Postgres installation from 7.4 to 8.2 (I know, I know, but
> we've been busy). The biggest thing to change will be our user/group
> management scripts, as they directly modify pg_shadow and pg_group. Beyond
> being potentially stupid (but hey, I didn't write it), this just won't work
> anymore, for a few reasons, which I will get to in a bit.
>
> What we used to do (all in a transaction block so it's nice and atomic):
> For users: Delete pg_shadow, read in logins/uids from /etc/passwd and create
> users, making sure the Unix uid matches up with the postgres sysid.
> For groups: For each group, drop the group, read in the new group from
> either another database table or some other mechanism.
>
> Now, having the Unix uids match up with the Postgres sysids isn't such a big
> deal since we'll be using Kerberos, which can presumably match up based on
> login name. It was nice to have them match up, but it's probably not
> necessary. However, the above mechanisms won't work for the following
> reasons:
>
> 1. pg_shadow and pg_group are now views, and you can't update views.
> 2a. Simply dropping a user is insufficient if the user owns anything in the
> database cluster.
> 2b. Deleting a user by removing the row from pg_authid works, but then the
> object owner is unknown and the object disappears unless you know where to
> look for it in the system tables. The objects are effectively orphaned.
> 3. There seems to be no way to recover the old sysid, as the "WITH SYSID
> uid" clause in CREATE USER/CREATE ROLE is now just noise, and trying to
> insert it directly into the system table proved fruitless. If you can't
> recover the old sysid, it leads to the orphaned objects problem described in
> 2b.
>
> So, I'm wondering how I can do something roughly equivalent to this, I've
> been considering using some sort of "diff"-like mechanism, but it'd be nice
> to have something simpler. Any help would be greatly appreciated.

You already stated there's no reason to have the ID's match, so why
bother? Just check each user/group name to see if it already exists and
add it if it doesn't.
--
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)