Extensions are not actors, so claiming that "the extension" did something is at best pretty fuzzy thinking.
Fair enough. The extension's includes code that stores logs into a table that is partitioned by timestamp. A function belonging to the extension is periodically called to rotate out the currently-active partition and create a new one.
> 4. After changing ACLs, the table is added to the extension (ALTER > EXTENSION) > 5. A pg_dump of this database will now include ACL commands for the > table.
Hmm. There's an argument to be made that ALTER EXTENSION ADD should absorb whatever the object's current ACLs are into the pg_init_privs entries for the extension. (I don't think it does that now, though I might be wrong.) However ...
Yes, that's what I'm arguing for. As I write this I see another message in which it looks like Stephen has agreed to look at this, so thank you Stephen!
> 6. A pg_restore of this file will give warnings because the ACLs refer > to a table that is not created as part of the installation process.
I think this scenario is simply pilot error, or at least gross abuse of the extension system. If you dump and reload a DB containing an extension, the extension definition that's fetched by CREATE EXTENSION is expected to define (at least) all the objects that belonged to the extension in the old DB. You can't just randomly ALTER EXTENSION and not update the extension definition script to match.
The reason I add the dynamically-created tables to the extension is so that they are never included in the pg_dump output. If this is a gross abuse of the extension system, is there another way you can suggest to mark these tables as not-to-be-dumped?