Skip site navigation (1) Skip section navigation (2)

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

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Dimitri Fontaine'" <dimitri(at)2ndQuadrant(dot)fr>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Fujii Masao'" <masao(dot)fujii(at)gmail(dot)com>, <cedric(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "'Robert Haas'"<robertmhaas(at)gmail(dot)com>, "'Greg Smith'" <greg(at)2ndquadrant(dot)com>, "'Josh Berkus'"<josh(at)agliodbs(dot)com>, "'Magnus Hagander'" <magnus(at)hagander(dot)net>, "'Christopher Browne'" <cbbrowne(at)gmail(dot)com>
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Date: 2012-11-19 14:46:55
Message-ID: 00ca01cdc664$b91f5500$2b5dff00$@kapila@huawei.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Monday, November 19, 2012 7:53 PM Dimitri Fontaine wrote:
> Amit Kapila <amit(dot)kapila(at)huawei(dot)com> writes:
> > We have discussion about below 3 different syntaxes for this command
> >
> > 1. ALTER SYSTEM
> > 2. SET PERSISENT
> > 3. pg_change_conf()
> >
> > I think to conclude, we need to evaluate which syntax has more
> advantages.
> > Comparison for above syntax
> 
> I think ALTER SYSTEM should be what Peter Eisentraut proposed in another
> thread, using system catalogs and thus not supporting the whole range of
> parameters and reset behavior on SIGHUP. That's still very useful, and
> seems to me clear enough to document.

> Then, I think you could implement a SET PERSISENT command that call the
> pg_change_conf() fonction. The problem is that you then can't have the
> command unavailable in a transaction block if all it does is calling the
> function, because the function call needs to happen in a transaction.

If we want to go for SET PERSISTENT, then no need of built-in function call
pg_change_conf(), 
the functionality can be implemented in some internal function.
I believe still avoiding start of transaction is un-avoidable, as even parse
of statement is called
after StartTransaction.
The only point I can see against SET PERSISTENT is that other variants of
SET command can be used in
transaction blocks means for them ROLLBACK TO SAVEPOINT functionality works,
but for SET PERSISTENT,
it can't be done. 
So to handle that might be we need to mention this point in User Manual, so
that users can be aware of this usage.
If that is okay, then I think SET PERSISTENT is good to go.

With Regards,
Amit Kapila.



In response to

Responses

pgsql-hackers by date

Next:From: Karl O. PincDate: 2012-11-19 14:50:04
Subject: Re: Doc patch, put RAISE USING keywords into a table
Previous:From: Dimitri FontaineDate: 2012-11-19 14:22:31
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group