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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
