Re: how to run encoding-dependent tests by default

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: how to run encoding-dependent tests by default
Date: 2019-06-17 16:39:21
Message-ID: 20190617163921.kjfyk3su6edhqyd2@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 making the testing more straightforward would be useful.
>
> The reason these tests cannot be run by default (other than that they
> don't apply to each build, which is easy to figure out) is that
>
> a) They contain UTF8 non-ASCII characters that might not convert to
> every server-side encoding, and
>
> b) The error messages mention the encoding name ('ERROR: collation
> "foo" for encoding "UTF8" does not exist')
>
> The server encoding can be set more-or-less arbitrarily for each test
> run, and moreover it is computed from the locale, so it's not easy to
> determine ahead of time from a makefile, say.
>
> What would be a good way to sort this out? None of these problems are
> terribly difficult on their own, but I'm struggling to come up with a
> coherent solution.

I wonder if using alternative output files and psql's \if could be good
enough here. It's not that hard to maintain an alternative output file
if it's nearly empty.

Basically something like:

\gset SELECT my_encodings_are_compatible() AS compatible
\if :compatible
test;
contents;
\endif

That won't get rid of b) in its entirety, but even just running the test
automatically on platforms it works without problems would be an
improvement.

We probably also could just have a wrapper function in those tests that
catch the exception and print a more anodyne message.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Darafei Komяpa Praliaskouski 2019-06-17 16:55:44 Re: initial random incompatibility
Previous Message Andrew Dunstan 2019-06-17 16:36:10 Re: how to run encoding-dependent tests by default