Re: Dumping an Extension's Script

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, 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-06 00:08:22
Message-ID: 18371.1354752502@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> 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.

A dump-level option for that seems completely wrong in any case: it
breaks one of the fundamental design objectives for extensions, or
at least for extensions as originally conceived. It might be necessary
to do it this way for these new critters, but that just reinforces the
point that you're designing a new kind of object.

I think a separate kind of "extension template" object would make a lot
more sense.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-06 00:13:40 Re: Fwd: question on foreign key lock
Previous Message Andres Freund 2012-12-05 23:55:30 Re: PITR potentially broken in 9.2