Re: Inline Extension

Поиск
Список
Период
Сортировка
От Dimitri Fontaine
Тема Re: Inline Extension
Дата
Msg-id 87lip3k9az.fsf@hi-media-techno.com
обсуждение исходный текст
Ответ на Re: Inline Extension  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Inline Extension  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Inline Extension  ("David E. Wheeler" <david@justatheory.com>)
Список 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 по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: Simulating Clog Contention
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Avoiding shutdown checkpoint at failover