Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in

From: "Ivan N(dot) Taranov" <i(dot)taranov(at)postgrespro(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in
Date: 2020-03-28 16:26:08
Message-ID: CAKqLMA_Ht5Hd-SyT=PQr8zjqtRNHSV2mkmN-Kifebkx6OAurDw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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!

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-03-28 17:13:54 Re: pg11+: pg_ls_*dir LIMIT 1: temporary files .. not closed at end-of-transaction
Previous Message Tom Lane 2020-03-28 15:54:48 Re: [PATCH] postgresql.conf.sample->postgresql.conf.sample.in