Re: Dumping an Extension's Script

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Well, with the design you have proposed, unless you have access to the
> filesystem, it ain't gonna work. And if you have access to the
> filesystem, then this whole discussion is moot.

I did mention that this version of the patch is only ready to host the
current design talk we have now. I intend to amend it with some inline
ALTER EXTENSION facility.

In the worked out example you gave in another mail of this thread, you
would have to remove any explicit ALTER EXTENSION … ADD … of course, as
in a classic script here.

You would have to fill in both the current and next version of the
extension I guess, as a defensive check, too.

> That doesn't impress me in the slightest. Suppose you have two
> identically configured machines A and B on which you install hstore
> (from the filesystem) and a hypothetical extension istore (via the
> inline extension mechanism). Now, you take regular backups of machine
> A, and one day it dies, so you want to restore onto machine B. Well,
> if you didn't dump with --extension-script, then you've got an
> incomplete backup, so you are hosed. And if you did dump with

You didn't ever restore your backup? So you didn't know for sure you had
one. More seriously…

> --extension-script, then you're OK in that scenario, but the wheels
> come off if you try to dump and restore onto machine C, which is
> running a newer version of PostgreSQL with an updated hstore. To do
> it right, you have to remember which extensions you installed which
> way and dump exactly the right thing for each one. That can't be
> good.

In the patch we're talking about, the --extension-script is an
accumulative option that needs an argument, so you do

pg_dump --extension-script istore --extension-script foo

or if you're into short options

pg_dump -X istore -X foo -X bar

I'm not saying that design is perfect nor definitive, it's just what
happens to be in the patch, and it allows you to solve your problem. We
could default the --extension-script to any installed extension for
which we don't have a control file?

> Like Andres, I'd like to see a reference to the thread where we
> supposedly had consensus on this behavior. I don't really recall us
> achieving consensus on anything, but if we did I have a hard time
> believing it was this.

What I remember about the "consensus" from last year is:

- http://archives.postgresql.org/pgsql-hackers/2012-01/msg01307.php

- inline and file based extensions must be the same beast once in the
database

- pg_dump options should work the same against either kind

- it all boils down to designing a consistent dump behavior

Which is the angle I've been working on reaching this round. The other
thing we said is more about how to get the dump's content, and I
realised that it could be so much simpler than relying on any file
anywhere: pg_extension and pg_depend have all the information we need.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support