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
