Re: format of pg_upgrade loadable_libraries warning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Daniel Gustafsson <daniel(at)yesql(dot)se>
Subject: Re: format of pg_upgrade loadable_libraries warning
Date: 2019-11-14 19:46:29
Message-ID: 8832.1573760789@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Oct-07, Bruce Momjian wrote:
>> and the "in database" (which I have changed to capitalized "In database"
>> in the attached patch), looks like:
>> fprintf(script, "In database: %s\n", active_db->db_name);
>> meaning it _isn't_ an output error message, but rather something that
>> appears in an error file. I don't think either of these are translated.
>> Is that wrong?

> pg_fatal is a "gettext trigger" (see nls.mk), so that part of the
> message is definitely translated.

Right, but Bruce's point is that what goes into the separate output
file listing problem cases is not translated, and never has been.
Maybe we should start doing so, but that would be a distinct issue.
I'm not really sure that we should translate it, anyway --- could
there be anyone out there who is using tools to process these files?

> BTW, how is one supposed to "manually upgrade databases that use
> contrib/isb"? This part is not very clear.

Agreed, the pg_fatal message is claiming that you can do something
without really providing any concrete instructions for it. I'm not
sure that that's helpful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-11-14 20:04:20 Re: Using multiple extended statistics for estimates
Previous Message Andrew Dunstan 2019-11-14 19:29:23 Re: ssl passphrase callback