Re: Dumping an Extension's Script

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dumping an Extension's Script
Date: 2012-12-05 19:54:57
Message-ID: 20121205195457.GE4673@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

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.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-12-05 20:16:52 Re: Dumping an Extension's Script
Previous Message David E. Wheeler 2012-12-05 19:52:42 Re: json accessors