Re: Review: extension template

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Review: extension template
Дата
Msg-id 51DC7AC5.5040005@gmx.net
обсуждение исходный текст
Ответ на Re: Review: extension template  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: Review: extension template  (Markus Wanner <markus@bluegap.ch>)
Список pgsql-hackers
On 7/8/13 4:20 AM, Dimitri Fontaine wrote:
> Let me stress that the most important value in that behavior is to be
> able to pg_restore using a newer version of the extension, the one that
> works with the target major version. When upgrading from 9.2 to 9.3 if
> you depend on keywords that now are reserved you need to install the
> newer version of the extension at pg_restore time.

I think there is an intrinsic conflict here.  You have things inside the
database and outside.  When they depend on each other, it gets tricky.
Extensions were invented to copy with that.  They do the job, more or
less.  Now you want to take the same mechanism and apply it entirely
inside the database.  But that wasn't the point of extensions!  That's
how you get definitional issues like, should extensions be dumped or not.

I don't believe the above use case.  (Even if I did, it's marginal.)
You should always be able to arrange things so that an upgrade of an
inside-the-database-package is possible before or after pg_restore.
pg_dump and pg_restore are interfaces between the database and the
outside.  They should have nothing to do with upgrading things that live
entirely inside the database.

There would be value to inside-the-database package management, but it
should be a separate concept.



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

Предыдущее
От: Dimitri Fontaine
Дата:
Сообщение: Re: robots.txt on git.postgresql.org
Следующее
От: "Prabakaran, Vaishnavi"
Дата:
Сообщение: Differences in WHERE clause of SELECT