Re: Dumping an Extension's Script

On Wed, Dec 5, 2012 at 5:08 PM, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Yeah, DROP will work. But what about ALTER .. UPDATE?
>
> What about it?

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.

>> Well, there's certainly a point, because IIUC Dimitri's patch dumps
>> the file into the pg_dump output no matter whether the file originally
>> came from an SQL command or the filesystem. IMHO, anyone who thinks
>> that isn't going to break things rather badly isn't thinking hard
>> enough.
>
> Only if you ask for it using --extension-script. The default behaviour
> didn't change, whether you decide to install your extension from the
> file system or the PostgreSQL port.

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
--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.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company