Re: [HACKERS] Development installation fails
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] Development installation fails |
Дата | |
Msg-id | Pine.LNX.4.20.9911281205410.3881-101000@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: [HACKERS] Development installation fails (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Development installation fails
|
Список | pgsql-hackers |
On 1999-11-24, Tom Lane mentioned: > > ~/postgres-cur/bin$ ./initdb --pglib=/home/peter/postgres-cur/lib \ > > --pgdata=/home/peter/postgres-cur/data > > You may need to have env variables PGDATA and PGLIB set during initdb > (at least, the install docs recommended that last I looked) and you > definitely need to have /home/peter/postgres-cur/bin in your PATH. Okay, thanks for the tip. I thought about this for a while and came to the conclusion, that this is not only the most likely reason for the oft criticized installation (non-)simplicity, it is also cumbersome and not acceptable to have to set environment variables (especially PATH) during installation. This would also mean that I would have to yank the path away from my production installation. So I thunk that initdb could very well find out itself where it is located and then call ${mydir}/postgres explicitly. That solves the path problem. Secondly, it could also make educated guesses where the PGLIB is at (namely ${mydir}/../lib, or ${mydir}/../lib/pgsql as in the RPMs). That solves the other problem. I included a patch that does exactly that, so now I can do: $ ./configure --prefix=/any/path/here $ make $ make install $ /any/path/here/bin/initdb -D /some/other/path #(*) $ /any/path/here/bin/postmaster -D /some/other/path and I'm up and running. (No PG* env var or special PATH is set.) I'm not kidding, this is exactly what I did (well, different path names) and I'm in business. Okay, there are some other glitches with make install and initdb being very reluctant to creating directories themselves, but that could be fixed in another round of changes. So please examine that patch. It was a very quick hack, so it's not very refined. Let me know if this sounds good, then I'll put the finishing touches on it. -Peter (*) - Notice that I changed the option to -D (formerly -r). This goes more nicely with the equivalent postmaster option, and also with "_D_at's where I want my data to be stored" :) -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
В списке pgsql-hackers по дате отправления: