David J N Begley <d.begley@uws.edu.au> writes:
> I have verified that _no_ GRANT/REVOKE commands are dumped for the database,
> and only some GRANT/REVOKE commands are dumped for "language" objects (see
> below);
The latter is not really a bug. Languages don't currently have owners
(ie there is no owner column in pg_language). For ACL-munging purposes
we act as though the bootstrap superuser owns the language, that is,
that userid is shown as the grantor of privileges. But having a
superuser revoke his own privileges is a no-op, because he's a superuser
and the privileges aren't going to be enforced against him anyway. So
the fact that pg_dump doesn't process that part of the ACL isn't very
meaningful.
Sooner or later we may get around to assigning explicit owners to
languages, but it's not a high-priority problem --- AFAICS the lack
of ownership doesn't create any problems worse than these sorts of
corner-case confusions. It'll always be true that superuserdom is
needed to create a PL, and distinguishing one superuser from another
is not a particularly useful activity in the context of permission
checks ...
I fooled around with having pg_dump explicitly treat the language as
being owned by the bootstrap superuser, and think I may apply the patch
now even though it doesn't really matter, because it does clean up the
output a little bit --- instead of
--
-- Name: pltcl; Type: ACL; Schema: -; Owner:
--
REVOKE ALL ON LANGUAGE pltcl FROM PUBLIC;
SET SESSION AUTHORIZATION postgres;
GRANT ALL ON LANGUAGE pltcl TO postgres;
RESET SESSION AUTHORIZATION;
SET SESSION AUTHORIZATION postgres;
GRANT ALL ON LANGUAGE pltcl TO tgl;
RESET SESSION AUTHORIZATION;
I get
--
-- Name: pltcl; Type: ACL; Schema: -; Owner: postgres
--
REVOKE ALL ON LANGUAGE pltcl FROM PUBLIC;
REVOKE ALL ON LANGUAGE pltcl FROM postgres;
GRANT ALL ON LANGUAGE pltcl TO postgres;
GRANT ALL ON LANGUAGE pltcl TO tgl;
for a pg_language ACL of "{postgres=U/postgres,tgl=U/postgres}".
Avoiding the SET SESSION AUTHORIZATIONs seems like a good idea.
regards, tom lane