On 2019-07-29 16:47, Tom Lane wrote:
>> (The two tests create the same schema name, so they cannot be run in
>> parallel. I opted against changing that here, since it would blow up
>> the patch and increase the diff between the two tests.)
>
> This does create one tiny nit, which is that the orde
Peter Eisentraut writes:
> On 2019-07-28 20:12, Tom Lane wrote:
>> So I wish we could get rid of the Makefile changes, have the test
>> scripts be completely responsible for whether to run themselves or
>> not, and put them into the schedule files normally.
> Good points. Updated patch attach.
On 2019-07-28 21:42, Tom Lane wrote:
> Oh ... one other thought, based on forcing the collate.linux.utf8
> test to run on platforms where it can be expected to fail: I think
> you'd be well advised to make that test verify that the required
> collations are present, the same as you did in the colla
On 2019-07-28 20:12, Tom Lane wrote:
> So I wish we could get rid of the Makefile changes, have the test
> scripts be completely responsible for whether to run themselves or
> not, and put them into the schedule files normally.
>
> It's pretty obvious how we might do this for collate.icu.utf8:
> m
Oh ... one other thought, based on forcing the collate.linux.utf8
test to run on platforms where it can be expected to fail: I think
you'd be well advised to make that test verify that the required
collations are present, the same as you did in the collate.icu.utf8
test. I noticed for instance tha
I wrote:
> I'm less clear on a reasonable way to detect a glibc platform
> from SQL. The best I can think of is to see if the string
> "linux" appears in the output of version(), and that's probably
> none too robust. Can we do anything based on the content of
> pg_collation? Probably not :-(.
Peter Eisentraut writes:
>> Cool, that works out quite well. See attached patch. I flipped the
>> logic around to make it \quit if not compatible. That way the
>> alternative expected file is shorter and doesn't need to be updated all
>> the time. But it gets the job done either way.
I took a
On 2019-06-23 21:44, Peter Eisentraut wrote:
> On 2019-06-17 18:39, Andres Freund wrote:
>> Basically something like:
>>
>> \gset SELECT my_encodings_are_compatible() AS compatible
>> \if :compatible
>> test;
>> contents;
>> \endif
>
> Cool, that works out quite well. See attached patch. I flipp
On 2019-06-17 18:39, Andres Freund wrote:
> Basically something like:
>
> \gset SELECT my_encodings_are_compatible() AS compatible
> \if :compatible
> test;
> contents;
> \endif
Cool, that works out quite well. See attached patch. I flipped the
logic around to make it \quit if not compatible.
Hi,
On 2019-06-17 16:56:00 +0200, Peter Eisentraut wrote:
> There is a fair amount of collation-related functionality that is only
> being tested by sql/collate.icu.utf8.sql and sql/collate.linux.utf8.sql,
> which are not run by default. There is more functionality planned in
> this area, so maki
On 6/17/19 11:32 AM, Tom Lane wrote:
> Peter Eisentraut writes:
>> There is a fair amount of collation-related functionality that is only
>> being tested by sql/collate.icu.utf8.sql and sql/collate.linux.utf8.sql,
>> which are not run by default. There is more functionality planned in
>> this a
Peter Eisentraut writes:
> There is a fair amount of collation-related functionality that is only
> being tested by sql/collate.icu.utf8.sql and sql/collate.linux.utf8.sql,
> which are not run by default. There is more functionality planned in
> this area, so making the testing more straightforwa
12 matches
Mail list logo
