On Fri, Feb 23, 2018 at 9:45 AM, Khushboo Vashi < khushboo.va...@enterprisedb.com> wrote:
> > > On Thu, Feb 22, 2018 at 5:32 PM, Dave Page <dp...@pgadmin.org> wrote: > >> >> >> On Thu, Feb 22, 2018 at 4:11 AM, Khushboo Vashi < >> khushboo.va...@enterprisedb.com> wrote: >> >>> >>> >>> On Wed, Feb 21, 2018 at 10:51 PM, Dave Page <dp...@pgadmin.org> wrote: >>> >>>> >>>> >>>> On Wed, Feb 21, 2018 at 3:45 PM, Joao De Almeida Pereira < >>>> jdealmeidapere...@pivotal.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 >> > >
