"Donald Fraser" <postgres@xxxxxxxxxxxxxxx> writes: > 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. It's not apparent to me why you have to control the userID in order to have an auxiliary table defining a user. You could do something like keeping the currently assigned OID in the aux table, setting the field to null or zero if the user doesn't currently exist in pg_authid. > 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. You ran that risk already with the SYSID scheme, no? regards, tom lane
