Richard Huxton <d...@archonet.com> writes:
> 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 is kind of problematic because it requires those tables to be
created before the extension is created. One difficulty with that is it
would break parallel pg_restore. Another is that it's not unusual for
the config tables to not be populatable at all before the extension's
been loaded. For example, IIRC how the old contrib/tsearch2 config
tables worked, there were regproc columns that contained references to
functions created by tsearch2.
It is true that the extension author may sometimes need to run some code
when the user-provided data is loaded into the config table, but in the
design I suggested, that could be handled by attaching triggers to the
config table.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
