On Fri, Jul 3, 2026 at 11:15 PM Tom Lane <[email protected]> wrote:
>
> Fujii Masao <[email protected]> writes:
> > I have one question, though.
>
> > Suppose a user executes GRANT or REVOKE on pg_get_ruledef(oid), then
> > creates a dump with pg_dump. If that dump is restored into a newer
> > server where these patches have been applied, the restore would fail
> > because pg_get_ruledef(oid) no longer exists.
>
> > Is that acceptable (this means that users need to handle the restore
> > failure), or should pg_dump handle this case specially?
>
> I wouldn't blink an eye at that. There's no obvious use-case for
> someone to mess with the permissions on that function. Even
> if there were, I don't think it'd be reasonable for pg_dump to
> try to patch it up. (I'm not sure that pg_dump would dump such
> grants in the first place.)
pg_dump seems to dump such grants. For example:
$ createuser foo
$ psql -c "REVOKE ALL ON FUNCTION pg_get_ruledef(oid) FROM public"
REVOKE
$ psql -c "GRANT ALL ON FUNCTION pg_get_ruledef(oid) TO foo"
GRANT
$ pg_dump | grep pg_get_ruledef
-- Name: FUNCTION pg_get_ruledef(oid); Type: ACL; Schema:
pg_catalog; Owner: postgres
REVOKE ALL ON FUNCTION pg_catalog.pg_get_ruledef(oid) FROM PUBLIC;
GRANT ALL ON FUNCTION pg_catalog.pg_get_ruledef(oid) TO foo;
My concern was simply that restoring such a dump into a newer server
could fail because the single-argument function like pg_get_ruledef(oid)
no longer exists. This could affect not only GRANT/REVOKE, but also
commands such as ALTER FUNCTION and COMMENT, etc.
So I just asked that question.
If we agree that these are fairly unlikely use cases, so no special
handling for such restore failures is necessary, I'm ok with that.
Regards,
--
Fujii Masao
