----- Original Message -----
From: "Tom Lane"
> "Donald Fraser" writes:
> > 1) Was there a good reason for dropping this feature?
> Users/groups are identified by OIDs now, not by sysids.
>
> The original motivation for allowing manual assignment of userids was to
> allow recovery if a user was dropped while still owning objects --- you
> could recreate the user with the same sysid and then the objects' owner
> fields would match up. 8.1 now does reference counting and prevents you
> from dropping users who still own anything, so AFAICS that use-case is
> gone. Do you have another one?
Yes we do have another use.
We developed and have been using since 7.1, and currently running 7.4,
bespoke client / database software. The ability to manage users and security
was of high priority and we therefore developed a much more elaborate user
definition where by the information about users was held in our own tables
and we could create a postgresql database user from this table at any time.
To simplify things we controlled the SYSID and used this as the key for
mapping a postgresql user to a user defined in our table.
Obviously we have the information in our table to go from a postgresql user
name back to the original SYSID but that process is messy and requires
string manipulation etc.
The ability to controll the SYSID, now labelled OID, basically allows for a
more elaborate third-party managment of postgresql users.
It is not impossible to use the postgresql user name to map into the table
we have created but it would be nicer and cleaner to be able to continue
using the OID.
I take it then that the patching of that feature would cause problems
because the OID is controlled by postgreql and we could therefore be trying
to create a user with an OID that could already be in use.
Regards
Donald Fraser
