Re: A different approach to extension NO USER DATA feature

Поиск
Список
Период
Сортировка
От Richard Huxton
Тема Re: A different approach to extension NO USER DATA feature
Дата
Msg-id 4D4FC284.4040704@archonet.com
обсуждение исходный текст
Ответ на A different approach to extension NO USER DATA feature  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: A different approach to extension NO USER DATA feature  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: Foreign servers and user mappings versus the extensions patch
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: SSI patch version 14