Re: pg_stat_database shows userid as OID - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_stat_database shows userid as OID
Date
Msg-id 200211172337.gAHNbqS08668@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_stat_database shows userid as OID  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: CLUSTER ALL syntax
Next
From: Bruce Momjian
Date:
Subject: Re: CLUSTER ALL syntax