Re: ALTER EXTENSION UPGRADE, v3

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: ALTER EXTENSION UPGRADE, v3
Дата
Msg-id BA570A77-5BD6-4432-9A80-3A077203FA54@kineticode.com
обсуждение исходный текст
Ответ на Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: ALTER EXTENSION UPGRADE, v3  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Feb 11, 2011, at 10:30 AM, Tom Lane wrote:

> No --- in the current vision, a control file may describe a whole
> collection of versions of the same extension, and the parameter in
> question is selecting the default or preferred version to install.
> I'm not wedded to "default_version", but I think just plain "version"
> is a misnomer.

current_version, then.

>> Oh, so what should oldv be to indicate creating from a legacy extension?
>
> In principle we are leaving it to the extension author to choose that.
> However, we're going to have to make a choice for the contrib modules,
> and I'll bet lunch that most people will follow whatever precedent we
> set with those.  I was thinking about using either "old" or "unpackaged".
> Thoughts?

unpackaged++

> It can be specified by a "directory" parameter in the control file,
> and defaults to the same place the control file is.  Right now, that's
> $PREFIX/share/contrib/.

Frankly, given the likely proliferation of upgrade scripts, I think it ought to be $PREFIX/share/contrib/$extension/

>  One other thing that ought to be discussed is
> whether to stick with that choice or change it.  Given that some people
> have great antipathy to the word "contrib", I suspect there will be
> argument to change it --- but to do so, I think we'd have to change the
> default MODULEDIR in PGXS, and I'm not sure that's a good idea.

Add EXTENSIONDIR and make it "extensions".

Best,

David



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

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: Debian readline/libedit breakage
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Range Types: empty ranges