Re: pg_upgrade's bindir options could be optional

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_upgrade's bindir options could be optional
Дата
Msg-id 2250.1304712695@sss.pgh.pa.us
обсуждение исходный текст
Ответ на pg_upgrade's bindir options could be optional  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: pg_upgrade's bindir options could be optional
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> Just a thought: To make things a bit easier, the bindir options of
> pg_upgrade (-b/-B, --old-bindir/--new-bindir) could be made optional, I
> think.  The new bindir should normally be the one that pg_upgrade itself
> is in.  And the old bindir could be found out by looking at the
> postmaster.opts file in the old data directory.  At least by default,
> this would make the pg_upgrade invocation a lot more compact; it would
> just be: pg_upgrade -d oldir -D newdir.

> Comments?

I don't think we should rely on postmaster.opts being there, let alone
being trustworthy.  It's probably not unreasonable to let --new-bindir
default to the directory pg_upgrade is in, but I'm much less comfortable
with allowing --old-bindir to be defaulted.

As an example, the proposed defaults would be not only wrong, but
disastrous in the perfectly-reasonable situation where the user has
moved the old installation aside and then installed the new executables
in the same place the old ones used to be.  My current RPM packaging of
pg_upgrade would be at risk for the same reason.
        regards, tom lane


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: VARIANT / ANYTYPE datatype
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: VARIANT / ANYTYPE datatype