Re: pg_stat_database shows userid as OID
От | Bruce Momjian |
---|---|
Тема | Re: pg_stat_database shows userid as OID |
Дата | |
Msg-id | 200211172337.gAHNbqS08668@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: pg_stat_database shows userid as OID (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
I totally agree with what you have said. Peter, can you clarify your reasoning for OID for user/group id? --------------------------------------------------------------------------- Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Tom Lane wrote: > >> I'd recommend not making any piecemeal changes, especially not when > >> there's not yet a consensus which way to converge. > > > Well, seems we should make it consistent at least. > > I think the original argument stemmed from the idea that we ought to use > pg_shadow's OID column as the user identifier (eliminating usesysid per > se). This seems like a good idea at first but I think it has a couple > of fatal problems: > * disappearance of pg_shadow.usesysid column will doubtless break some > applications > * if we use OID then it's much more difficult to support explicit > assignment of userid > > > I think some wanted it to be an int so they could use the > > same unix uid for pg_shadow, but I think we aren't using that idea much > > anymore. > > I don't think anyone worries about making usesysid match /etc/passwd > anymore, but nonetheless CREATE USER WITH SYSID is still an essential > capability. What if you drop a user accidentally while he still owns > objects? You *must* be able to recreate him with the same sysid as > before. pg_depend cannot save us from this kind of mistake, either, > since users span databases. > > So it seems to me that we must keep pg_shadow.usesysid as a separate > column and not try to make it the OID of pg_shadow. > > Given that decision, the argument for making it be type OID seems very > weak, so I'd lean to the "use int4" camp myself. But I'm not sure > everyone agrees. I think Peter was strongly in favor of OID when he > was revising the session-authorization code (that's why it all uses OID > for user IDs...) > > As far as the actual C code goes, I'd lean to creating new typedefs > UserId and GroupId (or some such names) and making all the routine > and variable declarations use those, and not either OID or int4. > But I'm not excited about promoting these typedefs into actual SQL > types, as was done for TransactionId and CommandId; the payback seems > much less than the effort needed. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: