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

Re: pgsql: Update for roles: < * Prevent default re-use of sysids for

От
Stephen Frost
Дата:
* 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

Вложения

Re: pgsql: Update for roles: < * Prevent default re-use

От
Bruce Momjian
Дата:
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

Re: pgsql: Update for roles: < * Prevent default re-use of sysids for

От
Stephen Frost
Дата:
* 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

Вложения

Re: pgsql: Update for roles: < * Prevent default re-use

От
Tom Lane
Дата:
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