Re: pg_config, pg_service.conf, postgresql.conf ....
От | Mark Kirkwood |
---|---|
Тема | Re: pg_config, pg_service.conf, postgresql.conf .... |
Дата | |
Msg-id | 4405046D.5080801@paradise.net.nz обсуждение исходный текст |
Ответ на | Re: pg_config, pg_service.conf, postgresql.conf .... (Andrew Dunstan <andrew@dunslane.net>) |
Список | pgsql-hackers |
Andrew Dunstan wrote: > > > Mark Kirkwood wrote: > >>> >>> >> >> Do you need name, value pairs? I was thinking that something like: >> >> # Postgres Cluster Registration >> # >> # PG_HOME PGDATA PORT >> /usr/local/pg7.4.1 /vol01/pggeo 5435 >> /usr/local/pg7.4.1 /vol01/pgicdmdb 5434 >> /usr/local/pg7.4.1 /vol03/pg74 5432 >> >> >> Clearly other fields are possible (like ALIAS for the names you were >> using, and OPTS for extra arguments). >> >> This sort of layout is easily readable (more easily readable for those >> of us used to standard UNIX config files) and simply parsable too. >> >> > > I am a Unix guy through and through, but its config files have pained me > many times over the years. Not least because of lack of consistency. > > This sort of layout fails miserably if there are optional fields. Look > at the handsprings we had to turn to put CIDR addresses into > pg_hba.conf. And not without debate. > > I don't much like ini style configs either. > > These days, for Perl apps I generally make the config file a perl hash, > which can be as deeply structured as you like. The great advantage is > that you get parsing for free. For other apps I'm mildly inclined to > YAML or XML configs. All of these might be verbose, but they have 2 huge > advantages: they can adapt to structure, and they are somewhat > self-documenting. I am currently wrestling with an app that does > horrible things because its config needs to be tree structured and is > instead flat (and also utterly unreadable). > I agree that if there are real requirements that demand (more than one) optional parameter(s), and tree structures, then by all means let's use a format that can handle them properly. However, it would be a shame to dive off into something complex if something simple would do. From what I've seen on this thread so far, the simple conf file is a good fit (unless I've missed something - always possible unfortunately :-) ). regards Mark
В списке pgsql-hackers по дате отправления: