Re: Extension security improvement: Add support for extensions with an owned schema

Hi Jelte,

> I also included a
> separate patch that fails the test_pg_dump regression test if any
> warning is emitted by pg_dump/pg_restore so that CI will catch these
> kind of failures in the future.

I checked that it would have caught this one. With v12-0001 on top
of v11, test_pg_dump fails 25 checks, all of them "pg_dump runs
without warnings" with the dependency loop warning. With v12 all
1182 pass. (v11 needed test_extensions added to EXTRA_INSTALL to run
on its own, which is the Makefile fix in v12.)

I re-ran the three cases from my earlier mail with the same scripts,
on master 3c5d9d914fa against a REL_18_STABLE (18.6) cluster:

- pg_dump, pg_dumpall and pg_upgrade from PG18 all work now;
pg_upgrade exits 0.
- The owned-schema extension dumps without warnings, plain and
--binary-upgrade, and restores with extownedschema = t.
- make -C src/test/modules/test_pg_dump check passes on its own.

Both patches apply cleanly and build without warnings, and
test_extensions, src/bin/pg_dump and src/bin/pg_upgrade pass.

One thing about the new comment in pg_dump.c:

We still keep the schema's dependency on the extension so the
schema's ACL and comment are dumped after CREATE EXTENSION creates
the schema.

The ACL is: a GRANT on the owned schema comes after CREATE EXTENSION
in the dump and survives a plain, directory and parallel restore.
The COMMENT is not dumped at all, so it is lost on restore. That
looks like the existing rule for extension members rather than
something this patch broke; on unpatched master a comment on a
function of an extension is lost the same way. But the schema is now
a member, so a schema comment that used to survive a dump/restore no
longer does, while a same-version pg_upgrade keeps it. Either the
code comment should only mention the ACL, or the owned schema's
comment could be dumped like its ACL.

Regards,
Manu