Fwd: pgsql: Emit parameter values during query bind/execute errors

On Tue, Dec 31, 2019 at 2:18 AM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> On 2019-Dec-12, Tom Lane wrote:
>
> > Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> > > Hmm, the affected ones (jacana and fairywren only AFAICS) seem to be
> > > gcc-based, which presumably work differently than the msvc-based in how
> > > newlines are interpreted in the test script. I pushed an attempted
> > > blind fix.
> >
> > > I *hope* that those two are not the only Windows ones running the
> > > pgbench tap test!
> >
> > [ scrapes buildfarm results... ] The Windows critters that are
> > running that test seem to be
> >
> > name | operating_system | compiler
> > -----------+------------------+---------------
> > bowerbird | Windows | Visual Studio
> > drongo | Windows | Visual Studio
> > fairywren | Windows / Msys | gcc
> > jacana | Windows | gcc
> >
> > So yeah, the MSVC ones were happy with the test as you had it.
> > Interesting ... it's not obvious why that would have anything
> > to do with the behavior of a Perl regexp. Maybe they are using
> > a different Perl version?
>
> Jacana seems to be using 5.8.8 according to $Config{version} (though
> 5.26 is in PATH, strangely); fairywren is 5.30.
>
> Bowerbird is 5.16.2 and Drongo 5.24.3.
>

The perl used to run prove is not the same on Msys as the perl we build
against. The former needs to be targeted at Msys, so it's the one that Msys
provides, but the latter needs to be pure Windows native, so we use
StrawberryPerl or ActivePerl.

So for fairywren we use 5.30.0 / 5.24.3 while on jacana we use 5.8.8 /
5.26.3. The former can be seen in the config bf_perl_version, while the
latter can be seen in the configure output.

For MSVC we use the same perl for both purposes.

>
> I don't think the buildfarm tells us about Perl internals to know if
> they interpret platform-dependent newlines differently.
>
> I suppose the difference might be the way Perl interprets the literal
> newline embedded in the regexp, versus how the log file is written.
> With the [\r\n]+ pattern the platform schizophreny no longer matters.
>
>
>
In general I don't think putting embedded newline literals inside a regex
is great practice. It's too easy to miss other trailing whitespace
characters. so I think the fix is an improvement anyway.

I normally spell this as \r?\n but as you say TIMTOWTDI.

cheers

andrew