Обсуждение: pgsql: Update for roles: < * Prevent default re-use of sysids for
pgsql: Update for roles: < * Prevent default re-use of sysids for
От
momjian@svr1.postgresql.org (Bruce Momjian)
Дата:
Log Message:
-----------
Update for roles:
< * Prevent default re-use of sysids for dropped users and groups
> * Prevent default re-use of sysids for dropped users and roles
450c450
< * Add COMMENT ON for all cluster global objects (users, groups, databases
> * Add COMMENT ON for all cluster global objects (users, roles, databases
609c609
< users and groups with separate DROP commands
> users and roles with separate DROP commands
Modified Files:
--------------
pgsql/doc:
TODO (r1.1583 -> r1.1584)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/TODO.diff?r1=1.1583&r2=1.1584)
pgsql/doc/src/FAQ:
TODO.html (r1.90 -> r1.91)
(http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/FAQ/TODO.html.diff?r1=1.90&r2=1.91)
* Bruce Momjian (momjian@svr1.postgresql.org) wrote:
> < * Prevent default re-use of sysids for dropped users and groups
> > * Prevent default re-use of sysids for dropped users and roles
sysids are gone, roles have Oids, so I don't think this is an issue
anymore... Users are gone too...
> 450c450
> < * Add COMMENT ON for all cluster global objects (users, groups, databases
> > * Add COMMENT ON for all cluster global objects (users, roles, databases
Users are gone, so this would just apply to roles..
> < users and groups with separate DROP commands
> > users and roles with separate DROP commands
users are gone, there are only roles, so I don't know that they'd need
separate DROP commands, if that's what this means? We do have DROP ROLE
and REVOKE ROLE...
Thanks,
Stephen
Вложения
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (momjian@svr1.postgresql.org) wrote:
> > < * Prevent default re-use of sysids for dropped users and groups
> > > * Prevent default re-use of sysids for dropped users and roles
>
> sysids are gone, roles have Oids, so I don't think this is an issue
> anymore... Users are gone too...
>
> > 450c450
> > < * Add COMMENT ON for all cluster global objects (users, groups, databases
> > > * Add COMMENT ON for all cluster global objects (users, roles, databases
>
> Users are gone, so this would just apply to roles..
Updated.
> > < users and groups with separate DROP commands
> > > users and roles with separate DROP commands
>
> users are gone, there are only roles, so I don't know that they'd need
> separate DROP commands, if that's what this means? We do have DROP ROLE
> and REVOKE ROLE...
The problem is this used in pg_dumpall --clean:
DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');
--
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, Pennsylvania 19073
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> The problem is this used in pg_dumpall --clean:
>
> DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');
Oh, wow. Hrmm. That certainly won't work now. It seems to me that the
correct thing to do here would be to loop through the roles and delete
them one-by-one, with cascade? I think that would clean things out
correctly. Alternatively I suppose you could delete from pg_authid and
pg_auth_members.. That seems a little ugly to me.
Thanks,
Stephen
Вложения
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> The problem is this used in pg_dumpall --clean:
> DELETE FROM pg_shadow WHERE usesysid <> (SELECT datdba FROM pg_database WHERE datname = 'template0');
Hmm. I haven't gotten around to looking at pg_dumpall issues, but we
might have to add an ON DELETE rule to the pg_shadow view to allow old
dump files to continue working.
IIRC, there are *really* old dump files that try to do COPY TO
pg_shadow, but I'm assuming we don't care about supporting stuff
that far back.
regards, tom lane