Re: more i18n/l10n issues - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: more i18n/l10n issues |
Date | |
Msg-id | 23949.1064845403@sss.pgh.pa.us Whole thread Raw |
In response to | Re: more i18n/l10n issues (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re: more i18n/l10n issues
(Bruce Momjian <pgman@candle.pha.pa.us>)
Re: more i18n/l10n issues (Bruce Momjian <pgman@candle.pha.pa.us>) Re: more i18n/l10n issues (Andrew Dunstan <andrew@dunslane.net>) Re: more i18n/l10n issues (Peter Eisentraut <peter_e@gmx.net>) |
List | pgsql-hackers |
Peter Eisentraut <peter_e@gmx.net> writes: > Dave Page writes: >> I find this a little worrying because if we want a feature or tweak for >> pgAdmin we usually have to fight tooth & nail to justify getting it >> committed (which is not a bad thing), however 'some guys at Red Hat' are >> getting switches added to the postmaster without any discussion? > It was not a nice thing to do. Gimme a break, guys. There *was* discussion, eg here, http://archives.postgresql.org/pgsql-hackers/2003-06/msg01092.php and the patch was posted for review, see this thread: http://archives.postgresql.org/pgsql-patches/2003-06/msg00420.php I'll admit that I applied the patch with more than usual speed, but that was because we were right up against our self-imposed feature freeze deadline for 7.4, and I didn't see any big objections. The biggest gripe left over at the end of the above-mentioned patches thread was that the message texts were unpolished, but as even Peter agreed, that could be fixed later. So MHO is let's fix them now. > Could whoever is responsible for this admin tool at Red Hat please specify > exactly what data they need out of this interface, so we have a chance to > make the interface a little more future-proof now and possibly remove some > of the unneeded clutter that is giving translators problems? The point was to allow a GUI utility to be built that would help in editing postgresql.conf. It couldn't assume the postmaster is already running, so just extending the pg_config view wouldn't answer, and duplicating knowledge of all the GUC variables in a separate tool would have created maintenance headaches. I would like to think that the patch would eventually allow us to generate postgresql.conf.sample automatically from the guc.c tables, and thereby reduce the number of files to maintain, but that didn't get done yet. The reason for having both "long" and "short" descriptions of the variables was that I foresaw the "short" versions as becoming the per-line comments in postgresql.conf. The "long" descriptions were what the GUI tool wants. regards, tom lane
pgsql-hackers by date: