>>> Really? We are removing usesysid? Seems the admin will no longer be
>>> able to choose the users id, right?
>>
>> Not that this was ever useful.
> Except for re-adding users.
Yes. In theory, the correct answer to that is to add referential
integrity checks that prevent you from dropping a user that still
owns any objects. In practice, this is impractical because users
span a whole database installation. We have no reasonable way to
check whether the user owns objects in other databases that cannot
be seen from the DB where we are issuing the DROP USER command.
Therefore, for the foreseeable future it will be important to be
able to reverse a DROP USER command --- ie, recreate a user with
the same user identifier previously used.
After thinking about that for awhile, I am inclined to change my
previous position: we should not switch over to using the OIDs of
pg_shadow rows as user identifiers. usesysid should continue to
exist. Ditto for groups --- grosysid can't go away either.
I think the original motivation for wanting to eliminate these columns
was that we need usesysid and grosysid to be distinct (can't use the
same ID for both a user and a group). Using OIDs as IDs would fix
that, but it's overkill. Wouldn't it be sufficient to use an
installation-wide sequence object to assign new IDs for new users and
groups? We have no such animals at the present, but I see no reason
why we couldn't make one.
regards, tom lane