Bruce Momjian escribió: > We already have six levels of GUC settings: > > postgresql.conf > user > database > session > function > subtransaction > > If we add ALTER SYSTEM SET and config.d, we would then have eight.
Actually, conf.d (not config.d) would just be reported as a file, and the "file" column in the pg_settings view would show which file it is. That's how it's done for postgresql.conf and any other file it includes, so that seems a pretty reasonable thing to me. > ALTER SYSTEM SET seems to add an entirely new set of behaviors and > complexity. Is that really what we want? I had imagined that ALTER SYSTEM SET would be represented in the same way as above, i.e. just be a different source file. But thinking more about it now, that doesn't make sense, because those files might be in a completely different base directory, and the file names shouldn't even be exposed to the user in the first place; so clearly ALTER SYSTEM should show up differently in pg_settings. Displaying each option's full path seems useful for troubleshooting, as you say: > If we do this, perhaps we should unconditionally just print the file > name they have to delete to undo the operation in case the server > doesn't start; However, bear in mind that if the DBA is administering a server through ALTER SYSTEM and they don't have shell access, they might just be screwed if they bollix the system and they lose access. Knowing what file you have to delete does you no good if you can't actually delete it. > I am unclear we can clearly identify all the GUC > settings that could cause a server not to start. Also, I think we need > a SHOW SYSTEM command so users can see their settings via SQL. Not sure about this. SHOW normally just displays the current value, nothing more. If you want more details, there's the pg_settings view with complete information. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
