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
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 straightforward would be useful.
The reason th
13 matches
Mail list logo
