Anssi Kääriäinen <anssi.kaariai...@thl.fi> writes:
> Ok, verified at least for CREATE OR REPLACE, ALTER FUNCTION RENAME and ALTER
> FUNCTION SET search_path. You will get the extensions version back when
> restoring from plain sql dump, not the CORed function, rename is lost and
> same for search_path. I suspect this is a problem for any object type
> supported in extensions. But unfortunately I do not have time to verify
> that.
Yes it's the same, if you edit an extension's object directly the edited
version is not in the dump. There's provision to have those objects in
the dump but the function to make it so is currently restricted to only
be called from the extension's script.
pg_extension_flag_dump() changes the dependency type between an
extension's and one of its object, given by oid. The default behavior
of an extension is to skip objects in pg_dump, but in some cases
that's not what you want to achieve, as an extension author. If your
extension provides user data (in a table, for example), then flag this
table so that it's part of the backups, like so:
SELECT pg_extension_flag_dump('schema.tablename'::regclass);
Maybe we should open this function so that it's usable even outside of
the extension's script, but I'm not keen on doing so.
Again, editing the extension's objects out of the scripts is still
limited to superusers and not the only way to shoot yourself in the
foot…
> One more problem with pg_dump. If you have CREATE EXTENSION in you
> extensions .sql file, you will have problems restoring. I know it is stupid
> to do so, but still CREATE EXTENSION inside CREATE EXTENSION should be
> disallowed, as it is possible you find out too late that this is stupid
> thing to do. Also, the functions created in the "recursive" CREATE EXTENSION
> will be dumped, and the dependencies are not created correctly.
That will be handled later, it's called inter-extension dependencies.
We said we won't address that yet…
> Unfortunately I have used up all the time I have for reviewing this patch. I
> can arrange some more time, maybe late this week, maybe a bit later. So, I
> do not have time to do the pg_dump part review in full detail right
> now. Still, I hope the work I have done is helpful.
Very much so, thanks a lot for the time you already spent on it!
> Should I write up a post that contains all the current outstanding issues in
> one post, or is it enough to just link this thread in the CommitFest
> application?
I'd appreciate a list of yet-to-fix items. What I have is the
search_path issue where CREATE EXTENSION foo; can leave it changed for
the current session, I intend to fix that later today.
Other than that, I have no further already agreed on code fix to make.
What's your list?
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
