Re: [HACKERS] bytea_output vs make installcheck - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] bytea_output vs make installcheck
Date
Msg-id B6EEEF4B-85A4-4AE5-854D-691E804701E4@anarazel.de
Whole thread Raw
In response to Re: [HACKERS] bytea_output vs make installcheck  (neha khatri <nehakhatri5@gmail.com>)
Responses Re: [HACKERS] bytea_output vs make installcheck  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: [HACKERS] bytea_output vs make installcheck  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers

On February 14, 2017 9:02:14 PM PST, neha khatri <nehakhatri5@gmail.com> wrote:
>On Wed, Feb 15, 2017 at 10:04 AM, neha khatri <nehakhatri5@gmail.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
pointfixing 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?

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



pgsql-hackers by date:

Previous
From: neha khatri
Date:
Subject: Re: [HACKERS] bytea_output vs make installcheck
Next
From: Joshua Chamberlain
Date:
Subject: [HACKERS] CREATE TABLE with parallel workers, 10.0?