[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
--
Attachments:
0001-postgresql.conf.sample-postgresql.conf.sample.in.patchtext/x-diff; charset=us-ascii; name=0001-postgresql.conf.sample-postgresql.conf.sample.in.patchDownload
From d8ac8bb8f49e8a528a3e89de38c23b014361dab3 Mon Sep 17 00:00:00 2001
From: "Ivan N. Taranov" <i.taranov@postgrespro.ru>
Date: Fri, 27 Mar 2020 22:27:08 +0300
Subject: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in
diff --git a/configure.in b/configure.in
index ecdf172396..c20992be77 100644
--- a/configure.in
+++ b/configure.in
@@ -2389,7 +2389,7 @@ fi
AC_SUBST(vpath_build)
-AC_CONFIG_FILES([GNUmakefile src/Makefile.global])
+AC_CONFIG_FILES([GNUmakefile src/Makefile.global src/backend/utils/misc/postgresql.conf.sample])
AC_CONFIG_LINKS([
src/backend/port/pg_sema.c:${SEMA_IMPLEMENTATION}
diff --git a/src/backend/utils/misc/.gitignore b/src/backend/utils/misc/.gitignore
index 495b1aec76..0adfc77197 100644
--- a/src/backend/utils/misc/.gitignore
+++ b/src/backend/utils/misc/.gitignore
@@ -1 +1,2 @@
/guc-file.c
+/postgresql.conf.sample
diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample.in
similarity index 100%
rename from src/backend/utils/misc/postgresql.conf.sample
rename to src/backend/utils/misc/postgresql.conf.sample.in
--
2.26.0
Import Notes
Reply to msg id not found: 948732f79b760bddc43505058f861033@postgrespro.ruReference msg id not found: 948732f79b760bddc43505058f861033@postgrespro.ru
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:
Show quoted text
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 = 16Why 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 renaming the 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 which this 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!