From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: pg_stat_database shows userid as OID |
Date: | 2002-11-22 05:40:26 |
Message-ID: | 200211220540.gAM5eQp10400@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Does anyone want userid to be an OID? Peter? Anyone?
If not, I will add it to the TODO list or work on the patch myself.
---------------------------------------------------------------------------
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-11-22 05:43:00 | Re: nested transactions |
Previous Message | Bruce Momjian | 2002-11-22 05:32:46 | nested transactions |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-11-22 05:41:01 | Re: 7.4 cube patch to add create cast |
Previous Message | Bruce Momjian | 2002-11-22 05:39:01 | Re: 7.4 patch for cube to handle extra_float_digits |