Re: PATCH: Report libpq version and configuration - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: PATCH: Report libpq version and configuration
Date
Msg-id 20201109160822.GA9777@alvherre.pgsql
Whole thread Raw
In response to Re: PATCH: Report libpq version and configuration  (Craig Ringer <craig.ringer@enterprisedb.com>)
Responses Re: PATCH: Report libpq version and configuration  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2020-Oct-27, Craig Ringer wrote:

> On Tue, Oct 27, 2020 at 12:56 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > +1.  Are we concerned about translatability of these strings?  I think
> > I'd vote against, as it would complicate applications, but it's worth
> > thinking about it now not later.
> 
> It's necessary not to translate the key names, they are identifiers
> not descriptive text. I don't object to having translations too, but
> the translation teams have quite enough to do already with user-facing
> text that will get regularly seen. So while it'd be potentially
> interesting to expose translated versions too, I'm not entirely
> convinced. It's a bit like translating macro names. You could, but ...
> why?

I don't think translating these values is useful for much.  I see it
similar to translating pg_controldata output: it is troublesome (to
pg_upgrade for instance) and serves no public that I know of.


> > Again, I'm not exactly excited about this.  I do not one bit like
> > patches that assume that x64 linux is the universe, or at least
> > all of it that need be catered to.  Reminds me of people who thought
> > Windows was the universe, not too many years ago.
> 
> Yeah. I figured you'd say that, and don't disagree. It's why I split
> this patch out - it's kind of a sacrificial patch.

Well, if we can make it run in more systems than just Linux, then it
seems worth having.  The submitted patch seems a little bit on the
naughty side.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: -O switch
Next
From: Stephen Frost
Date:
Subject: Re: Reduce the time required for a database recovery from archive.