| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
| Date: | 2012-11-13 18:45:16 |
| Message-ID: | CA+TgmoZ5zf1xvBaqtdQfbxV289zre88n+nVcx+jcWKegNeT6LA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 13, 2012 at 1:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> I was imagining writing single, specific settings, which inevitably
>> leads to one-setting-per-file, e.g.:
>
>> SET PERSISTENT work_mem = 256MB;
>
>> What Amit seems to be talking about is more EXPORT SETTINGS, where you
>> dump all current settings in the session to a file. This seems likely
>> to produce accidental changes when the user writes out settings they've
>> forgotten they changed.
>
> Yeah. It also seems to be unnecessarily different from the existing
> model of SET. I'd go with one-setting-per-command.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-11-13 18:54:45 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
| Previous Message | Robert Haas | 2012-11-13 18:43:34 | Re: Inadequate thought about buffer locking during hot standby replay |