locale/encoding vs vcregress.pl installcheck
vcregress's installcheck_internal has "--encoding=SQL_ASCII --no-locale"
hardcoded. It's been like that for a long time, for no good reason that
I can see. The practical effect is to make it well nigh impossible to
run the regular regression tests against any other encoding/locale. This
in turn has apparently masked an issue with the collate.windows.win1252
test, which only runs on a WIN1252-encoded database.
I propose simply to remove those settings for the installcheck target.
We already run the regression tests under these conditions in
'vcregress.pl check', so we wouldn't be giving up anything important.
Although this partcular test is only present in HEAD, I think we should
backpatch the change to all live branches.
(Yes, I know we are trying to get rid of these tools, but we haven't
done so yet. I'm working on it for the buildfarm, which is how I
discovered this issue.)
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
On 2023-02-25 Sa 12:13, Andrew Dunstan wrote:
vcregress's installcheck_internal has "--encoding=SQL_ASCII
--no-locale" hardcoded. It's been like that for a long time, for no
good reason that I can see. The practical effect is to make it well
nigh impossible to run the regular regression tests against any other
encoding/locale. This in turn has apparently masked an issue with the
collate.windows.win1252 test, which only runs on a WIN1252-encoded
database.I propose simply to remove those settings for the installcheck target.
We already run the regression tests under these conditions in
'vcregress.pl check', so we wouldn't be giving up anything important.
Although this partcular test is only present in HEAD, I think we
should backpatch the change to all live branches.(Yes, I know we are trying to get rid of these tools, but we haven't
done so yet. I'm working on it for the buildfarm, which is how I
discovered this issue.)
Done.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com