Re: User functions for building SCRAM secrets - Mailing list pgsql-hackers

On 2/14/23 3:19 PM, Jonathan S. Katz wrote:
> On 2/14/23 3:17 PM, Andres Freund wrote:

>> This reliably fails on CI:
>> https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest%2F42%2F3988
>>
>> I think this is related to encoding issues. The 32bit debian task
>> intentionally uses LANG=C. Resulting in failures like:
>>
https://api.cirrus-ci.com/v1/artifact/task/6696410851049472/testrun/build-32/testrun/regress/regress/regression.diffs
>>
>> Windows fails with a similar issue:
>> https://api.cirrus-ci.com/v1/artifact/task/5676064060473344/testrun/build/testrun/regress/regress/regression.diffs
> 
> Thanks for the explanation. I'll work on fixing that in the next go round.

(First -- I really like the current status of running the tests with 
Meson. I'm finding it very easy to use -- doing the locale testing was 
pretty easy too!)

I stared at this for a bit to see what we do in other regression tests 
using unicode strings. I looked at the regression tests for strings[1] 
and ICU collations[2].

In "strings", all the escaped Unicode strings are in the low bits so 
they're convertible to ASCII.

In the ICU test, it does a check to see if we're using UTF-8: if we're 
not, it bails.

For this patch, the value of the failing test is to ensure that the 
SCRAM function honors SASLprep when building the secret. It makes more 
sense to use the current character (U+1680), which will be converted to 
a space by the algorithm, vs. moving to U+0020 or something that does 
not exercise the SASLprep code.

I opted for the approach in [2]. v5 contains the branching logic for the 
UTF8 only tests, and the corresponding output files. I tested locally on 
macOS against both UTF8 +  C locales.

Thanks,

Jonathan

[1] 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/test/regress/sql/strings.sql
[2] 
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/test/regress/sql/collate.icu.utf8.sql