Re: Dumping an Extension's Script

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Dumping an Extension's Script
Дата
Msg-id CA+TgmoZF3iJ3c9GTfpwud4WFV2UMQtccbFAH5rKug3EsfJTzrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Dumping an Extension's Script  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: Dumping an Extension's Script
Re: Dumping an Extension's Script
Список pgsql-hackers
On Wed, Dec 5, 2012 at 12:47 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> For me it seems pretty natural to support dumping extension the way they
> got created. I.e. a plain CREATE EXTENSION ...; if the extension was
> preinstalled and some form that includes the extension source if you
> installed it via the connection.
>
> Extensions that were installed in some global manner *should* not be
> dumped with ones installed over the connection. E.g. dumping /contrib or
> packaged modules seems to be a bad idea to me.
>
> That would possibly be useful as a debugging tool, but I don't see much
> point besides that.

I agree with all of that.

What I can't quite figure out is - AIUI, extensions are a way of
bundling shared libraries with SQL scripts, and a way of managing the
dump and restore process.  If you just have SQL, there's no bundling
to do, and if you reverse out the pg_dump changes (which is more or
less what's being proposed here), then what do you have left other
than the good feeling of being "part of an extension"?  At that point,
it seems to me that you've gone to a lot of work to add a layer of
packaging that serves no real purpose.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: json accessors
Следующее
От: Robert Haas
Дата:
Сообщение: Re: autovacuum truncate exclusive lock round two