Re: Locale dependency in new postgres_fdw test

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Locale dependency in new postgres_fdw test
Date: 2017-07-21 22:50:17
Message-ID: 16313.1500677417@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:
> Tom Lane wrote:
>> We could stabilize this test result by forcing lc_messages = C in
>> the foreign server options. However, that would lose regression
>> coverage of situations where the remote locale is different, which
>> doesn't seem like a terribly good thing.

> I don't understand what is the benefit of having a different locale
> setting if there's no way that the test would pass except with a very
> specific locale. In other words, what coverage are we really losing by
> going this route?

What the current situation proves (or at least gives evidence for)
is that postgres_fdw doesn't have hidden dependencies on the remote server
running with the same lc_messages that prevails locally. As an example
--- admittedly a bit far-fetched, because this shouldn't ever get past
code review --- if postgres_fdw were checking for the presence of specific
strings in error messages from the remote, we could hope that the
buildfarm would catch that. But if we force the remote lc_messages value
throughout the test, we lose that type of coverage.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-07-21 23:04:32 Re: pg_stop_backup(wait_for_archive := true) on standby server
Previous Message Julien Rouhaud 2017-07-21 22:25:36 Re: segfault in HEAD when too many nested functions call