Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
От | Matthias Schmidt |
---|---|
Тема | Re: somebody working on: Prevent default re-use of sysids for dropped users and groups? |
Дата | |
Msg-id | 37F457DC-4878-11D9-B1AB-000393AA75A0@mock-software.de обсуждение исходный текст |
Ответ на | Re: somebody working on: Prevent default re-use of sysids for dropped users and groups? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
|
Список | pgsql-hackers |
Am 06.12.2004 um 23:27 schrieb Tom Lane: > 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 > > makes totally sense to me. Let's wait for Alvaro's stuff. By the way: Do you have an idea about a small or medium sized task from the TODO-List for a newbee, which gets me up to speed?(!Win32) The TODO-List is a good starting point, but I cannot figure out who works on what. cheers, Matthias ---------------------------------------------------------------------- Matthias Schmidt Viehtriftstr. 49 67346 Speyer Tel.: +49 6232 4867 Fax.: +49 6232 640089
В списке pgsql-hackers по дате отправления: