Re: location of the configuration files
От | Lamar Owen |
---|---|
Тема | Re: location of the configuration files |
Дата | |
Msg-id | 200302152203.56392.lamar.owen@wgcr.org обсуждение исходный текст |
Ответ на | Re: location of the configuration files (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: location of the configuration files
|
Список | pgsql-hackers |
On Saturday 15 February 2003 21:06, Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Shouldn't we be consistent and have initdb use the datadir set in the > > config file, which could be supplied by a ./configure switch? > That'd mean there is no way to perform an initdb into a nonstandard > location without first hand-preparing a config file. I don't much care > for that. Six of one and half-dozen of another. And that's my real point. We do things quite differently from many other standard services, even those which are built from the ground up for multiple instances. Making things more consistent for admins, even if it's not what we are used to or what we might like (because it's familiar) should at least be thought about. I'm not advocating changing just for the sake of change; but getting a new fresh look at our current setup can't hurt. > > I'm looking at a packager point of view here. The initdb is done well > > after the package is made, and installed. It would be ideal from this > > point of view to have things fully configured pre-initdb (and thus > > pre-packaging). > This point of view means that no post-configure knowledge can be > applied. We might as well forget the separate initdb step altogether > and have "make install" do it. I wouldn't complain. Although that isn't conducive to the multiple instance case. The necessary post-configure knowledge would be in the instance postgresql.conf file. One place for it. But this is hypothetical; fishing around the waters here at this point. Realize that my own packages apply an initdb automatically if an install isn't found the first time the system initscript is started. It is virtually automatic. With the multiple postmaster support, creating a couple of files and a symlink (for the initscript), and starting the new initscript symlink does all the dirty work. But it could be easier. > I realize that from a packager's point of view, the separate initdb step > is not very useful. But it is from my point of view. Would you mind elucidating which point of view is yours? General idea of who else might have the same point of view, and why you find the initdb in its current form to be more useful than alternatives. Again, I'm fishing for knowledge -- if nothing else it gives me an answer to those users who send me nastygrams about the way things are right now. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
В списке pgsql-hackers по дате отправления: