Re: Proposal for Allow postgresql.conf values to be changed via SQL
От | Amit Kapila |
---|---|
Тема | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Дата | |
Msg-id | 007001cdc726$248ae720$6da0b560$@kapila@huawei.com обсуждение исходный текст |
Ответ на | Re: Proposal for Allow postgresql.conf values to be changed via SQL (Amit Kapila <amit.kapila@huawei.com>) |
Ответы |
Re: Proposal for Allow postgresql.conf values to be
changed via SQL
|
Список | pgsql-hackers |
On Monday, November 19, 2012 9:07 PM Amit Kapila wrote: > On Monday, November 19, 2012 8:36 PM Alvaro Herrera wrote: > > Amit Kapila escribió: > > > > > 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. > > > > I think that's okay. There are other commands which have some forms > > that can run inside a transaction block and others not. CLUSTER is > > one example (maybe the only one? Not sure). > > In that case, it can have one more advantage that all configuration > setting > can be done with one command > and in future we might want to have option like BOTH where the command > will > take effect for memory as well > as file. > > Can you think of any strong reason why not to have with Alter System > Command? > > In any case SET PERSISTENT is fine. If no objections to SET PERSISTENT .. syntax, I shall update the patch for implementation of same. With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: