Re: somebody working on: Prevent default re-use of sysids for dropped users and groups? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
Date
Msg-id 7167.1102372052@sss.pgh.pa.us
Whole thread Raw
In response to Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?  (schmidtm <schmidtm@mock-software.de>)
Responses Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
List pgsql-hackers
schmidtm <schmidtm@mock-software.de> writes:
> Do I get that right: the only reason to do max(sysid) or a
> user-supplied ID in CreateUser() (commands/user.c) is that we don't
> have the ability to get sequences over the *.BKI/initdb mechanism?

No, that's not quite the direction of the problem.  The real reason
those facilities are there is so that you can deliberately create a user
having a previously-used sysid.  And the only reason why that is needed
is that we don't have dependency tracking for references to users and
groups.  If you could be certain that there were no remaining references
to a userid when it is dropped, there would be no need to be able to
resurrect it.  And that would mean that we could forget the whole sysid
assignment mess and just use the regular OID generator to create unique
IDs for users and groups.

Using a shared sequence instead of max(sysid) would be merely an
incremental improvement in the existing sysid assignment rules --- it
wouldn't eliminate the entire kluge at one blow.

So if Alvaro's thing works out, the shared-sequence problem becomes moot.
Probably that's a good reason not to spend time on it just yet.
        regards, tom lane


pgsql-hackers by date:

Previous
From: alex@pilosoft.com
Date:
Subject: Re: DBD::PgSPI 0.02
Next
From: Neil Conway
Date:
Subject: branch for 8.0?