On Sun, Jun 1, 2025, at 18:04, Tom Lane wrote: > I'm pretty skeptical that this situation justifies the amount of > pg_depend bloat that you're suggesting. I also don't think it'd be > easy or cheap for pg_dump to detect objects that should be dumped > because they lack an 'e' dependency but depend on objects that do > have one. Normally, because extension member objects aren't dumped, > pg_dump doesn't even collect info on their indexes etc. > > In short, it seems like quite a lot of work and quite a lot of > overhead (paid by everybody) to accommodate somebody abusing > extensions in one very specific way. There are a lot of scenarios > in which a cowboy DBA can cause the database contents to differ > from what the extension scripts say, and most of them would not > be helped by what you're suggesting.
Thanks for the detailed explanation. I underestimated the complexity involved in modifying pg_dump to handle this case, and given other cowboy cases would still remain, I see why it's not worth a core fix just for this single case. This reinforces my thinking that there's high value in improving tooling in this area outside of core PostgreSQL. I suggest a minimal change to the docs, to clarify that manually-added subsidiary objects on extension tables will not be preserved by pg_dump since they're not explicitly tracked as extension members. Attached is a proposed improvement for the documentation. /Joel
doc-extension-subsidiary-note.patch
Description: Binary data
