Re: Proposal for Allow postgresql.conf values to be changed via SQL

On Tuesday, November 13, 2012 11:43 PM Josh Berkus wrote:
> On 11/12/12 7:59 PM, Amit kapila wrote:
> > On Monday, November 12, 2012 12:07 PM Greg Smith wrote:
> > On 11/9/12 11:59 PM, Amit kapila wrote:
> >
> >>> Please let me know if there are any objections or problems in above
> method of implementation,
> >>> else I can go ahead to prepare the patch for the coming CF.
> >
> >> It may be the case that the locking scheme Robert described is the
> best
> >> approach here. It seems kind of heavy to me though. I suspect that
> >> some more thinking about it might come up with something better.
>
> So, here's the problem I'm seeing with having a single .auto file: when
> we write settings to a file, are we writing a *single* setting or *all
> of a user's current settings*?

Single setting.

> I was imagining writing single, specific settings, which inevitably
> leads to one-setting-per-file, e.g.:
>
> SET PERSISTENT work_mem = 256MB;

Yes, from beginning what I was discussing was setting of single config parameter as in your example.
However, it can be done with one-file for all variables as well.
I have already mentioned 2 ways of doing it, one is fixed format and fixed size file, other is similar to what Robert has detailed
in his mail (http://archives.postgresql.org/pgsql-hackers/2012-11/msg00572.php).

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

I think may be I was not clear enough in my previous mails, but for sure whatever I am talking is never related to
"dump all current settings in the session to a file".
In fact both my ideas (fixed format file, initial proposal) was not to touch or check the current session parameters.
There is only one Approach which is to see if from GUC, we can write the file that talks about writing multiple parameters.

With Regards,
Amit Kapila.