On Mon, Jun 16, 2014 at 12:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > On Sun, Jun 15, 2014 at 6:29 PM, Christoph Berg <c...@df7cb.de> wrote: >> >> Re: Amit Kapila 2014-06-13 >> <CAA4eK1KLn1SmgVtd=5emabqxrrpveedtbuu94e-repmwxwv...@mail.gmail.com> >> > Agreed, I had mentioned in Notes section of document. Apart from that >> > I had disallowed parameters that are excluded from postgresql.conf by >> > initdb (Developer options) and they are recommended in user manual >> > to be not used in production. >> >> Excluding developer options seems too excessive to me. ALTER SYSTEM >> should be useful for developing too. > > Developer options are mainly for debugging information or might help in one > of the situations, so I thought somebody might not want them to be part of > server configuration once they are set. We already disallow parameters like > config_file, transaction_isolation, etc. which are disallowed to be set in > postgresql.conf. Could you please explain me a bit in which > situations/scenarios, do you think that allowing developer options via Alter > System can be helpful?
I think that's helpful. I've heard that some users enable the developer option "trace_sort" in postgresql.conf in order to collect the information about sorting. They might want to set trace_sort via ALTER SYSTEM, for example. > This information is not stored in pg_settings. One way is to specify > manually all the parameters which are disallowed but it seems the query > will become clumsy, another could be to have another column in pg_settings. > Do you think of any other way? I like the latter idea, i.e., exposing the flags of GUC parameters in pg_settings, but it seems overkill just for tab-completion purpose. I'd withdraw my comment. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
