Re: Inline Extension - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Inline Extension
Date
Msg-id 87lip3k9az.fsf@hi-media-techno.com
Whole thread Raw
In response to Re: Inline Extension  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Inline Extension  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Inline Extension  ("David E. Wheeler" <david@justatheory.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> Frankly I don't see the point of this. If the extension is an independent
> piece of (SQL) code, developed separately from an application, with its own
> lifecycle, a .sql file seems like the best way to distribute it. If it's
> not, ie. if it's an integral part of the database schema, then why package
> it as an extension in the first place?

It allows to easily deploy an extension to N databases (my current use
case has 256 databases) and knowing which version is installed on each
server. It's easier to QA your procedures and upgrades when they are
packaged as extensions, too.

Now, for the dependency on a SQL file hosting the content, it's easier
to just connect to the databases and get them the script in the SQL
command rather than deploying a set of files: that means OS level
packaging, either RPM or debian or some other variant. Or some other
means of easily deploying the files. An SQL connection is all you need
if you're not shipping .so.

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


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Simulating Clog Contention
Next
From: Simon Riggs
Date:
Subject: Re: Avoiding shutdown checkpoint at failover