Обсуждение: 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