Re: Extensions not dumped when --schema is used
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Guillaume Lelarge <guillaume@lelarge.info>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-20T09:26:36Z
Lists: pgsql-hackers
> On 20 May 2020, at 10:06, Guillaume Lelarge <guillaume@lelarge.info> wrote: > I was wondering the reason behind this choice. If anyone knows, I'd be happy to hear about it. Extensions were dumped unconditionally in the beginning, but it was changed to match how procedural language definitions were dumped. > * it's been overlooked, and we should dump all the extensions available in a schema if this schema has been selected through the --schema flag. For reference, --schema-only will include all the extensions, but not --schema=foo and not "--schema-only --schema=foo". Extensions don't belong to a schema per se, the namespace oid in pg_extension marks where most of the objects are contained but not necessarily all of them. Given that, it makes sense to not include extensions for --schema. However, that can be considered sort of an implementation detail which may not be entirely obvious to users (especially since you yourself is a power-user). > * it's kind of like the large objects handling, and I'd pretty interested in adding a --extensions (as the same way there is a --blobs flag). An object in a schema might have attributes that depend on an extension in order to restore, so it makes sense to provide a way to include them for a --schema dump. The question is what --extensions should do: only dump any extensions that objects in the schema depend on; require a pattern and only dump matching extensions; dump all extensions (probably not) or something else? cheers ./daniel
Commits
-
Tweak behavior of pg_dump --extension with configuration tables
- 344487e2db03 14.0 landed
-
Remove duplicated --no-sync switches in new tests of test_pg_dump
- 885a87641930 14.0 landed
-
Add support for --extension in pg_dump
- 6568cef26e0f 14.0 landed