Re: pg_stat_database shows userid as OID

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_stat_database shows userid as OID
Date: 2002-11-17 23:37:52
Message-ID: 200211172337.gAHNbqS08668@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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(at)candle(dot)pha(dot)pa(dot)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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-11-17 23:43:38 Re: CLUSTER ALL syntax
Previous Message Tom Lane 2002-11-17 22:58:23 Re: CLUSTER ALL syntax

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2002-11-17 23:43:38 Re: CLUSTER ALL syntax
Previous Message Tom Lane 2002-11-17 22:58:23 Re: CLUSTER ALL syntax