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
Re: more i18n/l10n issues
Re: more i18n/l10n issues
Re: more i18n/l10n issues
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:

Previous
From: Eric B.Ridge
Date:
Subject: Re: [GENERAL] Can't Build 7.3.4 on OS X
Next
From: Christof Petig
Date:
Subject: Re: Alter Table Column Datatype