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!
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 |