I wrote:
>> I bet what is happening on drongo is that the compiler has generated a
>> __FILE__ value that contains backslashes not slashes, and this code
>> doesn't know how to shorten those. So maybe instead of lobotomizing
>> this test, we should fix that.
> Did that, but we'll have to wait a few hours to see if it makes
> drongo happy.
On third thought, maybe we should push your patch too. Although I think
53aafdb9f is going to fix the platform-specific aspect of this, we are
still going to risk some implementation dependence of the libpq_pipeline
results:
* Every so often, the number of digits in the reported line numbers
will change (999 -> 1001 or the like), due to changes in unrelated
code.
* Occasionally we refactor things so that the "same" error is reported
from a different file.
It's hard to judge whether that will happen often enough to be an
annoying maintenance problem, but there's definitely a hazard.
Not sure if we should proactively lobotomize the test, or wait to
see if we get annoyed.
In any case I'd like to wait till after drongo's next run, so
we can confirm whether or not the backslashes-in-__FILE__ hypothesis
is correct. If it is, then 53aafdb9f is a good fix on its own
merits, independently of libpq_pipeline.
regards, tom lane