Re: Proposal for Allow postgresql.conf values to be changed via SQL
От | Robert Haas |
---|---|
Тема | Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Дата | |
Msg-id | CA+TgmoZH6nM_1ojDLgBD66iZ3n2TR=bXPwN==jBSW5E2Nek54g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal for Allow postgresql.conf values to be changed via SQL (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal for Allow postgresql.conf values to be changed via SQL
Re: Proposal for Allow postgresql.conf values to be changed via SQL |
Список | pgsql-hackers |
On Sat, Dec 1, 2012 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > I wrote: >> But even if we can't make that work, it's not grounds for reserving >> PERSISTENT. Instead I'd be inclined to forget about "RESET PERSISTENT" >> syntax and use, say, SET PERSISTENT var_name TO DEFAULT to mean that. >> (BTW, I wonder what behavior that syntax has now in your patch.) > > In fact, rereading this, I wonder why you think "RESET PERSISTENT" > is a good idea even if there were no bison issues with it. We don't > write RESET LOCAL or RESET SESSION, so it seems asymmetric to have > RESET PERSISTENT. I think this feature is more analagous to ALTER DATABASE .. SET or ALTER ROLE .. SET. Which is, incidentally, another reason I don't like SET PERSISTENT as a proposed syntax. But even if we stick with that syntax, it feels weird to have an SQL command to put a line into postgresql.conf.auto and no syntax to take it back out again. We wouldn't allow a CREATE command without a corresponding DROP operation... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: