Re: somebody working on: Prevent default re-use of sysids for dropped users and groups?
От | Tom Lane |
---|---|
Тема | Re: somebody working on: Prevent default re-use of sysids for dropped users and groups? |
Дата | |
Msg-id | 7167.1102372052@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: somebody working on: Prevent default re-use of sysids for dropped users and groups? (schmidtm <schmidtm@mock-software.de>) |
Ответы |
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? |
Список | 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 по дате отправления: