Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607 - Mailing list pgsql-bugs

From Tom Lane
Subject Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
Date
Msg-id 151229.1717455291@sss.pgh.pa.us
Whole thread Raw
In response to Re: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607  (Thomas Munro <thomas.munro@gmail.com>)
Responses RE: [EXTERNAL] Re: Windows Application Issues | PostgreSQL | REF # 48475607
List pgsql-bugs
Thomas Munro <thomas.munro@gmail.com> writes:
> One open question is whether we should ship a translation file
> ourselves.  I have heard two opinions: Tom Lane proposed in this
> thread that there should be no file initially, we let the user figure
> out what to put in there.  Magnus Hagander proposed at the pgconf.dev
> conference last week that we should ideally ship a complete
> translation file and maintain it over time, and it should be installed
> not in pgdata but rather in the install directory.

FWIW, I'm kind of down on the latter approach, because I don't think
it'll move the needle very far.  Based on track record so far, there's
no chance that we will be aware of a Microsoft locale renaming before
it starts breaking users' databases.  Therefore, "edit the translation
file" is going to have to be a documented process in any case, because
affected users are not going to want to wait around for our next
release for a fix.  Also, if people do have to do that, it doesn't
seem like a great idea to tell them to modify an installed file rather
than a cluster-local configuration file.  What if they do a minor
version update but the minor version doesn't (yet) contain the fix?

Admittedly, the installed-file approach could make it more transparent
for people who'd done a PG minor update before the relevant Windows
update.  I'm not sure how large that set of people will be, though.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #18483: Segmentation fault in tests modules
Next
From: David Rowley
Date:
Subject: Re: BUG #18365: Inconsistent cost function between materialized and non-materialized CTE