Re: more i18n/l10n issues - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: more i18n/l10n issues |
Date | |
Msg-id | 200309291557.h8TFva724393@candle.pha.pa.us Whole thread Raw |
In response to | Re: more i18n/l10n issues (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
Should we allow SHOW ALL to show these variable descriptions? --------------------------------------------------------------------------- Tom Lane wrote: > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: