Re: Locale dependency in new postgres_fdw test

I wrote:
> I had not realized (or forgot) that postgres_fdw allows the remote
> end to run in whatever lc_messages locale is default for the remote
> installation. It's a bit surprising that none of the existing test
> cases expose any remote-side messages directly, but evidently not.

> 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.

It turns out that that way doesn't fix the problem, anyway, because
an lc_messages setting in the startup packet is applied too late
to change the output for the errors we're interested in. There have
been past discussions about maybe fixing that, but it's certainly
not happening now, much less in back branches.

BTW, I found out while trying to do that that ALTER SERVER does not
accept "options '-c lc_messages=C'" anyway, which surprised me quite
a bit. The reason turns out to be that libpq labels "options" as a
debug option which causes postgres_fdw to ignore it. Should we think
about changing that? Being able to set GUC variables for the remote
session seems useful.

> Another option is to temporarily set VERBOSITY to "terse" so that
> the DETAIL is suppressed from the test output. But then we don't
> really know why the connection failed, so that could mask issues
> that the test case ought to find, too.

So we're stuck with that solution. The disadvantage of not being
entirely sure why the connection failed could be solved if psql had
some way to report just the SQLSTATE of the last failure. I think
there's been some discussions about saving error SQLSTATEs into a
special variable, as we do for LASTOID for instance; but it doesn't
look like that's actually been done yet. We should revisit this
if that feature ever materializes.

regards, tom lane