Skip site navigation (1) Skip section navigation (2)

Re: Inline Extension

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Inline Extension
Date: 2012-01-19 16:15:27
Message-ID: 22486.1326989727@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> writes:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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.

I'm with Heikki on not believing that this is a good idea.  If you are
trying to do careful versioning of a set of object definitions, you want
to stick the things in a file, you don't want them just flying by in
submitted SQL.  Also, a large part of the point of the extension
facility is to be able to do uninstall/reinstall and version
upgrades/downgrades, none of which are possible unless the extension
scripts are stored somewhere.

ISTM your distribution concern would be much better addressed by
installing contrib/adminpack and then just using pg_file_write()
to put the new extension script into the remote server's library.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2012-01-19 16:46:02
Subject: Re: Simulating Clog Contention
Previous:From: Robert HaasDate: 2012-01-19 16:12:52
Subject: Re: Simulating Clog Contention

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group