| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Josh Berkus <josh(at)agliodbs(dot)com> |
| Cc: | Amit kapila <amit(dot)kapila(at)huawei(dot)com>, Greg Smith <greg(at)2ndQuadrant(dot)com>, "'Robert Haas'" <robertmhaas(at)gmail(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:16:11 |
| Message-ID: | 22895.1352830571@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gavin Flower | 2012-11-13 18:23:38 | Re: Inadequate thought about buffer locking during hot standby replay |
| Previous Message | Josh Berkus | 2012-11-13 18:13:08 | Re: Proposal for Allow postgresql.conf values to be changed via SQL |