Re: more i18n/l10n issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: more i18n/l10n issues
Date
Msg-id 200309291558.h8TFwfT24514@candle.pha.pa.us
Whole thread Raw
In response to Re: more i18n/l10n issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: more i18n/l10n issues
List pgsql-hackers
And maybe show the descriptions in pg_settings too?

---------------------------------------------------------------------------

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:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump no longer honors --no-reconnect
Next
From: Bruce Momjian
Date:
Subject: Re: pg_dump no longer honors --no-reconnect