Tom Lane writes:
> Hmm. So the real story here is that the permissions set up by initdb
> for PUBLIC are actually an illegal state: postgres has granted
> permissions to public that it isn't allowed to.
Yes, the way the permissions are initialized in the catalog templates
DATA(insert OID = 11 ( "pg_catalog" PGUID "{=U}" ));
DATA(insert OID = 99 ( "pg_toast" PGUID "{=}" ));
DATA(insert OID = 2200 ( "public" PGUID "{=UC}" ));
produce an invalid state. I hadn't thought that this would create a
problem for pg_dump, but I will hurry up fixing it. (I will probably put
explicit GRANT commands into initdb.)
> (There may also be an issue with the order in which pg_dump issues its
> revoke/grant operations, ie, there might be legal combinations that it
> can't reproduce.)
If you don't do manual surgery on aclitem's then I am convinced that it is
not possible to arrive at an undumpable state. This is a consequence of
the way it's implemented.
--
Peter Eisentraut [EMAIL PROTECTED]
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
