Re: A different approach to extension NO USER DATA feature

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