From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Donald Fraser" <postgres(at)kiwi-fraser(dot)net> |
Cc: | "[ADMIN]" <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: WITH SYSID feature dropped |
Date: | 2005-12-20 16:59:49 |
Message-ID: | 525.1135097989@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
"Donald Fraser" <postgres(at)kiwi-fraser(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2005-12-20 17:03:46 | Re: WITH SYSID feature dropped |
Previous Message | Tom Lane | 2005-12-20 16:37:14 | Re: PostgreSQL 7.4.10 hanging on delete |