Re: PATCH: Report libpq version and configuration
От | Alvaro Herrera |
---|---|
Тема | Re: PATCH: Report libpq version and configuration |
Дата | |
Msg-id | 20201109160822.GA9777@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: PATCH: Report libpq version and configuration (Craig Ringer <craig.ringer@enterprisedb.com>) |
Ответы |
Re: PATCH: Report libpq version and configuration
|
Список | 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 по дате отправления: