Re: A different approach to extension NO USER DATA feature

On Feb6, 2011, at 19: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.  An extension that wants to make use of that
> ability would probably need to add a boolean column "system_data" or
> something similar to its configuration tables.  Having done so,
> the extension's SQL script could call a function that identifies the
> configuration table and tells how to decide which rows to dump,
> along the lines of

We could avoid the need for a per-row "system_data" flag if we required
extensions to split user-editable and system-provided configuration data
into different tables. For convenient access to the configuration data,
the extension could let the user-editable table inherit from the 
system-provided one, or use a view to combine the two.

We'd then only need a per-table flag which tells pg_dump to dump the
data (but not the structure), so instead of a
 pg_extension_partial_dump (table_name regclass, where_condition text)

we'd have
 pg_extension_userdata(table_name regclass).

Apart from getting rid of the slightly ugly userdata flag-column, this
would also make it easier for users to distinguish between user-editable
and system-provided configuration options.

best regards,
Florian Pflug