On Sun, Apr 04, 2021 at 03:08:02PM -0700, Noah Misch wrote: > On Wed, Mar 31, 2021 at 09:37:44AM +0900, Michael Paquier wrote: > > On Tue, Mar 30, 2021 at 12:02:45PM +0900, Michael Paquier wrote: > > > Okay. So I have looked at that stuff in details, and after fixing > > > all the issues reported upthread in the code, docs and tests I am > > > finishing with the attached. The tests have been moved out of > > > src/bin/pg_dump/ to src/test/modules/test_pg_dump/, and include both > > > positive and negative tests (used the trick with plpgsql for the > > > latter to avoid the dump of the extension test_pg_dump or any data > > > related to it). > > > > I have double-checked this stuff this morning, and did not notice any > > issues. So, applied. > > I noticed the patch's behavior for relations that are members of non-dumped > extensions and are also registered using pg_extension_config_dump(). It > depends on the schema: > > - If extschema='public', "pg_dump -e plpgsql" makes no mention of the > relations. > - If extschema='public', "pg_dump -e plpgsql --schema=public" includes > commands to dump the relation data. This surprised me. (The > --schema=public argument causes selectDumpableNamespace() to set > nsinfo->dobj.dump=DUMP_COMPONENT_ALL instead of DUMP_COMPONENT_ACL.) > - If extschema is not any sort of built-in schema, "pg_dump -e plpgsql" > includes commands to dump the relation data. This surprised me. > > I'm attaching a test case patch that demonstrates this. Is this behavior > intentional?
I think this is a bug in $SUBJECT.
