From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Magnus Hagander" <magnus(at)hagander(dot)net> |
Cc: | "Csaba Nagy" <nagy(at)ecircle-ag(dot)com>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Permanent settings |
Date: | 2008-02-19 16:58:21 |
Message-ID: | 87fxvoyjbm.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Magnus Hagander" <magnus(at)hagander(dot)net> writes:
> Yeah, that may actually be a very good way to implement it. I don't like
> the idea of continously appending to an existing file, but if we did have a
> separate file with a tightly controlled format that would be doable.
+1
Separating the automatically written configuration and the explicit user
configuration is definitely the right approach. My experience comes from
Debian where packages editing their own configuration files is verboten.
Otherwise you run into problems reconciling user-made changes and automatic
changes.
The include file method is workable but isn't perfect. What happens if a user
connects with pgadmin and changes a parameter but that parameter is overridden
by a variable in the config file?
The alternative is to have two files and read them both. Then if you change a
variable which is overridden by the other source you can warn that the change
is ineffective.
I think on balance the include file method is so much simpler that I prefer it.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training!
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-02-19 17:11:05 | Re: Including PL/PgSQL by default |
Previous Message | David Fetter | 2008-02-19 16:41:56 | Including PL/PgSQL by default |