----- 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
