Обсуждение: [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

--

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!