Re: [pgAdmin4][Patch]: RM #3077 - ERROR: invalid byte sequence for encoding "LATIN1":0x00

On Fri, Feb 23, 2018 at 9:45 AM, Khushboo Vashi <
khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:

>
>
> On Thu, Feb 22, 2018 at 5:32 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>
>>
>>
>> On Thu, Feb 22, 2018 at 4:11 AM, Khushboo Vashi <
>> khushboo(dot)vashi(at)enterprisedb(dot)com> wrote:
>>
>>>
>>>
>>> On Wed, Feb 21, 2018 at 10:51 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Feb 21, 2018 at 3:45 PM, Joao De Almeida Pereira <
>>>> jdealmeidapereira(at)pivotal(dot)io> wrote:
>>>>
>>>>> Hi
>>>>> The patch looks good, do we have any example error that we can test in
>>>>> order to ensure the problem no longer shows up in the future?
>>>>> If they could be Unit Tests instead of Feature tests that would be
>>>>> awesome, because Feature tests are much more expensive then Unit.
>>>>>
>>>>
>>>> I think we need to consider a couple of options here:
>>>>
>>>> 1) Make sure that many/all of our tests use non-ASCII names.
>>>>
>>>> +1
>>>
>>>> 2) Consider adding a mechanism to allow running the regression tests
>>>> with overridden GUC values. For example, a parameter in the test config
>>>> file that gives a set of GUCs to change upon connection.
>>>>
>>>> The downside of 2 of course, is that it adds a huge amount of possible
>>>> environment combinations to test.
>>>>
>>>> We should implement this as it would be very helpful in reducing the
>>> testing efforts.
>>> But as you said there will be large set of combinations, so first we
>>> need to come up with the possible combinations which we would like to
>>> include first.
>>>
>>
>> Well, we could just update the framework to include a list of GUCs and
>> values in the JSON config, then we can test in different configs as needed.
>>
>> Sure. I will create one ticket for the same.
>
>>
>> Created the ticket #3144.

> --
>> Dave Page
>> Blog: http://pgsnake.blogspot.com
>> Twitter: @pgsnake
>>
>> EnterpriseDB UK: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>