Re: User functions for building SCRAM secrets

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