Re: bytea_output vs make installcheck

On Tue, Feb 14, 2017 at 9:17 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:

>
>
> On February 14, 2017 9:02:14 PM PST, neha khatri <nehakhatri5(at)gmail(dot)com>
> wrote:
> >On Wed, Feb 15, 2017 at 10:04 AM, neha khatri <nehakhatri5(at)gmail(dot)com>
> > wrote:.
> >>
> >>
> >>> Attached are two options for doing that. One overrides bytea_output
> >>> locally where-ever needed, and the other overrides it for the entire
> >>> 'regression' database.
> >>>
> >>
> >> The solution that overrides bytea_output locally looks appropriate.
> >It may
> >> not be required to change the format for entire database.
> >> Had there been a way to convert bytea_output from 'hex' to 'escape'
> >> internally, that could have simplified this customization even more.
> >>
> >
> >Well, the conversion from 'hex' to 'escape' is available using the
> >function
> >encode().
> >So the queries that are failing due to the setting bytea_output =
> >escape,
> >can be wrapped under encode(), to obtain the result in 'escape' format.
> >Here is another way to resolve the same problem. The patch is attached.
>
> I don't quite see the point of this - there's a lot of settings that cause
> spurious test failures. I don't see any point fixing random cases of that.
> And I don't think the continual cost of doing so overall is worth the
> minimal gain.
>
> What's your reason to get this fixed?
>

More testing is better than less testing, and a good way to get less
testing is requiring the tester to memorize a list of false positives they
might encounter. I'd like to systematically clone my production system,
run it through pg_upgrade, and then do installcheck (plus my own
app-specific) on the result, and I'd like others to do that as well with
their own production systems.

I don't really see the cost here. It took me longer to satisfy myself that
this was not actually a real bug than it did to write the patch. Now much
of that time was just because there were 3 other problems as well, which
makes isolating and evaluating them exponentially harder--which itself is a
good reason for fixing the ones that are easy to fix, so we don't have to
get distracted by those while investigating the other ones. And if we go
with the option 2 patch, it is one line which seems pretty self-documenting
and easy to maintain. I'd rather light a candle than to curse the darkness,
at least when the candle is this easy to light.

Cheers,

Jeff