Peter Eisentraut <pete...@gmx.net> writes: > My radical proposal therefore would have been to embrace this > inconsistency and get rid of PGC_BACKEND and PGC_SU_BACKEND altogether, > relying on users interpreting the parameter names to indicate that > changing them later may or may not have an effect. Unfortunately, the > concerns about ignore_system_indexes prevent that.
Yeah, I think making ignore_system_indexes USERSET would be a pretty bad idea. People would expect that they can frob it back and forth with no impact other than performance, and I'm doubtful that that's true. If we wanted to make a push to get rid of PGC_BACKEND, I could see changing ignore_system_indexes to SUSET category, and assuming that superusers are adults who won't push a button just to see what it does. But having said that, I don't really think that PGC_BACKEND is a useless category. It provides a uniform way of documenting that changing a particular setting post-session-start is useless. Therefore I'm not on board with getting rid of it. To the extent that we can make ALTER ROLE/DATABASE control these settings, that would be a good thing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers