Re: Dumping an Extension's Script

On Wed, Dec 5, 2012 at 2:54 PM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas escribió:
>> I have no objection whatsoever to the concept of storing the SQL and
>> control files somewhere that doesn't need access to the server
>> filesystem - in fact, I think I previously proposed allowing those to
>> be stored in a database table. You could do that with something like:
>>
>> CREATE TEMPLATE yadda;
>> ALTER TEMPLATE yadda ADD FILE 'yadda--1.0.sql' CONTENT $$...$$;
>>
>> ...or whatever.
>
> This seems unnecessary to me. What the patch at hand does is take the
> file (actually, the contents of the file) and execute it directly,
> without installing anything on disk. The precise contents of the
> extension is still tracked through pg_depend, so you can drop it without
> having previously saved neither the control file or the SQL script. (In
> fact, that's how DROP EXTENSION works currently.)

Yeah, DROP will work. But what about ALTER .. UPDATE?

> There's also the pg_dump side of things; with your proposal we would be
> forced to move over the yadda--1.0.sql file from the old server to the
> new one; or, equivalently, put the whole ALTER TEMPLATE .. CONTENT
> command in the dump, which is equivalent to what Dimitri's patch does;
> so there doesn't seem to be a point.

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.

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