David J N Begley <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq