On 06/02/11 18:23, Tom Lane wrote:
After a bit of thought I believe that we can fix this if we are willing
to teach pg_dump explicitly about extension configuration tables.
The behavior we want for those is for the table schema definition to
never be dumped (the table should always be created by CREATE EXTENSION),
but for some subset of the table data to get dumped, excluding any
system-provided rows.
[snip]
pg_extension_partial_dump (table_name regclass, where_condition text)
Possible alternative approach?
1. Extension provides list of config tables/views/set-returning
functions to be dumped via e.g. my_config_tables()
2. They get dumped, but each as a TEMP TABLE (need unique names for
multiple extensions though).
3. On restore, tables are created and populated, then
read_your_config(<ARRAY-OF-TABLE-NAMES>) is called in the extension.
This separates the configuration-for-user from
configuration-for-extension. It allows the extension to decide whether
to load the new config or reject it. It lets you test/demonstrate
multiple configurations fairly simply.
The "system_data" column scenario can then be a default implementation
of read_your_config().
--
Richard Huxton
Archonet Ltd
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
