On Tue, Jun 13, 2006 at 11:11:26PM +0200, Martijn van Oosterhout wrote: > I think my actual point was something else. We currently get calls from > people trying to administer machines that it's annoying that various > configuration information is stored in files, beyond the easy reach of > SQL.
While that would be a nice feature I don't see yet how this should work in detail. > What I was thinking is why we couldn't just store the information in a > global shared system table that is only read on config reload. You > could have a few columns, maybe the first being a list name, which is > referenced from a GUC. > [...] Similarly, it would also give a way for user-interfaces to get a > list of available valid timezones and their actual meanings, which is > currently impossible. I think you'll get lots of problems when you only read the table on config reload. First you get inconsistencies. I update the table with new timezone data and have to SIGHUP postmaster to read in the new table. In the meantime users get a wrong list of available timezones. Next, how does all that work with transactions and visibility? What if I update and send SIGHUP, what gets applied while I have not yet committed? And when the transaction rolls back, which version is active? Third, what about dumping and restoring? Dumping would have to compare the built-in set with the active settings and generate SQL commands from it, right? Restoring would execute them and - to make that active - reload the configuration which could have the side effects of activating other settings. > Just a thought really... Here as well :-) The config-by-sql approach seems to need some more specifications. If nobody objects, I'll submit the patch in the form that it reads from a file, as Tom pointed out this is a setting that gets only changed by few people and moreover it's not part of regular administrator's work (like changes to pg_hba.conf for example). Right now you have to get pgsql's source and recompile, so having to edit a file and sending a SIGHUP seems to be quite an improvement already. Getting a list of active timezones could be easily done with a system view but you might not want to promise its existence when you think about moving the whole thing to a system catalog later... Joachim ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
