Re: Extensions not dumped when --schema is used

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.