Обсуждение: postconfig/PGLIB/initdb

Поиск
Список
Период
Сортировка

postconfig/PGLIB/initdb

От
Peter Eisentraut
Дата:
As I already hinted a while ago, I am trying to resolve some of the
various shell scripts' obscure dependencies on various environment
variables and paths. My question is whether the use of the program
postconfig to determine the PGLIB value (or anything else, since there are
no checks done) is still encouraged/desired/done. To be clear: Contrary
to what some of you might start to believe, I do not want to remove every
little feature in PostgreSQL that I don't like/understand/use ;) I'm just
wondering.

My survey showed that the only two places where PGLIB is used is
createlang and initdb, so in a normal environment there is no good reason
to have PGLIB set all the time, anyway. In a developer's environment,
where these commands are executed many times, PGLIB is going to mess you
up if you want to install several versions, which is exactly the reason
why I am looking at this.

I found a pretty fool-proof (and with Tom's help portable) way to
determine the location of the needed files (the bki's and the PL handlers)
from the actual location of the shell script, and if that fails (which it
shouldn't) you can always use the --pglib/-L option. This will, unless you
intentionally use a particularly evil installation layout, ensure that any
initdb or createlang (or whatever else might use this) call is always
going to use the correct files and backend version without you having to
do any setting of anything (including PATH).

So, to summarize:
* PGLIB, keep it or lose it?
* postconfig, keep it or lose it?

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden




Re: [HACKERS] postconfig/PGLIB/initdb

От
Tom Lane
Дата:
Peter Eisentraut <peter_e@gmx.net> writes:
> So, to summarize:
> * PGLIB, keep it or lose it?

I had assumed that PGLIB was used for dynamic loading of extension
modules, but I now see that it isn't.  It's primarily used by initdb
to find the data files needed for initialization of template1.  AFAICT
it's not used by a running postmaster or backend at all.

If you can reliably find the location of the executing script, I
think it'd be a fine idea to lose PGLIB and instead get the data
files from "BINDIR/../lib/".  One less setting to get wrong.

(I'm not convinced yet about that "if", though.  Do you have a
substitute for "which" that you think is portable?  How can we
test it?)

> * postconfig, keep it or lose it?

Since postconfig is invoked as just "postconfig", trying to use it
introduces a very strong dependency on PATH.  I've never used it
so maybe I'm not seeing what it's good for --- but my guess is that
in the situation where you've got multiple versions installed, trying
to use postconfig would just result in confusion and havoc.  And in
the case where you have only one installation, it's not necessary.

I'm not really seeing what postconfig brings to the party.  If you
want the config to depend on your path, you can put the appropriate
BINDIR in your path, no?
        regards, tom lane