Alvaro Herrera <alvherre@commandprompt.com> writes:
> function <link linkend="functions-extension">pg_extension_flag_dump</link>
[...]
> So presumably this shouldn't be documented because it cannot be called
> anyway?
It can be called but only from an extension's script.
> To be honest I don't understand the purpose of this part of the patch.
So the problem we're offering a solution for, here, is the extension
with user data problem: the extension infrastructure is only there so
that pg_dump knows to filter OUT sql objects from its dump, prefering a
single create extension command. Some extension allows users to control
the data in some of they're objects: now you want to have those in the
backup again.
From the docs:
http://pgsql.tapoueh.org/extensions/doc/html/functions-admin.html#FUNCTIONS-EXTENSION
pg_extension_with_user_data allows extension's author to prepare installation scripts that will work well for initial
installationand when restoring from a pg_dump backup, which issues CREATE EXTENSION foo WITH NO USER DATA;. See CREATE
EXTENSIONfor details. One way to use it is as following:
DO $$ BEGIN IF pg_extension_with_user_data() THEN create schema foo; create table foo.bar(id serial primary
key); perform pg_extension_flag_dump('foo.bar_id_seq'::regclass); perform
pg_extension_flag_dump('foo.bar::regclass); END IF; END; $$;
I don't really know how to improve the docs, you seem to have been
surprised by reading the CREATE EXTENSION docs but you didn't follow the
link to the function's doc with the above details, did you?
I'm open to improving things here, but I'm not seeing how yet.
> I attach some minor fixes while reading it over. I compiled but didn't
> run it :-)
Thanks a lot, that's applied in my git repo, and I did run it
successfully! It will be part of the next patch revision.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support