"Donald Fraser" <postgres@kiwi-fraser.net> 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