Re: more i18n/l10n issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: more i18n/l10n issues
Date: 2003-09-29 14:23:23
Message-ID: 23949.1064845403@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christof Petig 2003-09-29 14:28:41 Re: Alter Table Column Datatype
Previous Message Marc G. Fournier 2003-09-29 14:14:30 Re: 2-phase commit