Thread: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in
A patch for converting postgresql.conf.sample to postgresql.conf.sample.in . This feature allows you to manage the contents of postgresql.conf.sample at the configure phase. Usage example: ./configure --enable-foo configure.in: foo_params=$(cat <<-END foo_param1 = on foo_param2 = 16 END ) AC_SUBST(foo_params) postgresql.conf.sample.in: @foo_params@ postgresql.conf.sample: foo_param1 = on foo_param2 = 16 --
Attachment
On 2020-03-28 10:00, i.taranov@postgrespro.ru wrote: > A patch for converting postgresql.conf.sample to > postgresql.conf.sample.in . This feature allows you to manage the > contents of postgresql.conf.sample at the configure phase. > > Usage example: > > ./configure --enable-foo > > > configure.in: > > foo_params=$(cat <<-END > foo_param1 = on > foo_param2 = 16 > END > ) > AC_SUBST(foo_params) > > > postgresql.conf.sample.in: > > @foo_params@ > > > postgresql.conf.sample: > > foo_param1 = on > foo_param2 = 16 Why do we need that? We already have the capability to make initdb edit postgresql.conf. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
This is usable for build installable postgresql.conf.SAMPLE. At the configure phase, it is possible to include / exclude parameters in the sample depending on the selected options (--enable - * / - disable- * etc ..) On Sat, Mar 28, 2020 at 2:21 PM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > > On 2020-03-28 10:00, i.taranov@postgrespro.ru wrote: > > A patch for converting postgresql.conf.sample to > > postgresql.conf.sample.in . This feature allows you to manage the > > contents of postgresql.conf.sample at the configure phase. > > > > Usage example: > > > > ./configure --enable-foo > > > > > > configure.in: > > > > foo_params=$(cat <<-END > > foo_param1 = on > > foo_param2 = 16 > > END > > ) > > AC_SUBST(foo_params) > > > > > > postgresql.conf.sample.in: > > > > @foo_params@ > > > > > > postgresql.conf.sample: > > > > foo_param1 = on > > foo_param2 = 16 > > Why do we need that? We already have the capability to make initdb edit > postgresql.conf. > > -- > Peter Eisentraut http://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
"Ivan N. Taranov" <i.taranov@postgrespro.ru> writes: > This is usable for build installable postgresql.conf.SAMPLE. At the > configure phase, it is possible to include / exclude parameters in the > sample depending on the selected options (--enable - * / - disable- * > etc ..) I'm with Peter on this: you're proposing to complicate matters for no real gain. As a former packager, I can readily imagine situations where somebody wants to adjust the initial contents of postgresql.conf compared to what's distributed --- I've done it myself. But anybody who's in that situation has got lots of other tools they can use for the purpose (patch(1) being a pretty favorite one, since it can also apply other sorts of code changes). Even more to the point, they've probably got an existing process for this, which would be needlessly broken by renaming the file as-distributed. Also, of the various ways that one might inject a modification, editing the configure.in file and then having to re-autoconf is one of the more painful ones, probably only exceeded by trying to maintain a patch against configure itself :-( As far as the project's own internal needs go, we do already have cases where configure's choices need to feed into postgresql.conf, but having initdb do all the actual editing has worked out fine for that. I don't think splitting the responsibility between configure time and initdb time would be an improvement --- for one thing, it'd be more painful not less so to deal with cases where considerations at both levels affect the same postgresql.conf entries. So if you want this proposal to go anywhere, you need a much more concrete and compelling example of something for which this is the only sane way to do it. regards, tom lane
Patch - yes, a good way. but 1) requires invasion to the makefile 2) makes changes in the file stored on git.. in case postgresql.conf.sample.in is a template, there are no such problems. and this does not bother those who if someone assumes the existence of the postgres.conf.sample file >Even more to the point, they've probably got an existing process for this, which would be needlessly broken by renamingthe file as-distributed. I agree, this is a serious reason not to do this, especially if the vendor stores changes in postgres.conf.samle in git > So if you want this proposal to go anywhere, you need a much more concrete and compelling example of something for whichthis is the only sane way to do it. This feature seems usable for preparing a certain number of packages consisting of different features. Each feature can have its own set of sample settings in postgres.conf.sample. In this case, using makefile + patch is more ugly. In any case, I am grateful for the answer and clarification!