| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Parsing config files in a directory |
| Date: | 2009-10-26 13:12:17 |
| Message-ID: | 603c8f070910260612r6e0686acmb58f7207644d323a@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Oct 26, 2009 at 12:18 AM, Greg Smith <gsmith(at)gregsmith(dot)com> wrote:
> On Sun, 25 Oct 2009, Robert Haas wrote:
>
>> I especially don't believe that it will ever support SET PERSISTENT, which
>> I believe to be a feature a lot of people want.
>
> It actually makes it completely trivial to implement. SET PERSISTENT can
> now write all the changes out to a new file in the include directory. Just
> ship the database with a persistent.conf in there that looks like this:
This only sorta works. If the changes are written out to a file that
is processed after postgresql.conf (or some other file that contains
values for those variables), then someone who edits postgresql.conf
(or some other file) by hand will think they have changed a setting
when they really haven't. On the flip side, there could also be still
other files that are processed afterwards, in which case SET
PERSISTENT would appear to work but not actually do anything.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dave Page | 2009-10-26 13:13:23 | Re: License clarification: BSD vs MIT |
| Previous Message | Alvaro Herrera | 2009-10-26 13:11:39 | Re: Proposal: String key space for advisory locks |