There are two means of loading user defined pattern tables.
ydb_pattern_file + ydb_pattern_table env vars. The ydb_pattern_file env var points to the file containing one or more pattern tables. The ydb_pattern_table points to one of the table names in that file. If these env vars are set, YottaDB loads the pattern table identified as the default pattern table. This allows user-defined pattern tables to be loaded even in UTF-8 mode as long as the integer codes (which satisfy a PATCODE) are < 128 (whereas in M mode, the integer codes can be < 256).
VIEW "PATLOAD" + $$set^%PATCODE mechanism (corresponds to ydb_pattern_file + ydb_pattern_table above). Except that we have a check in the % routine (patcode.mpt) about UTF-8 mode and a blanket refusal to load the table in that case.
I think this is a misfeature. Both schemes should be equivalent/consistent. The fact that a VIEW "PATLOAD" (which is always run implicitly or explicitly before the $$set^%PATCODE) succeeded means there was no integer code > 127 and if so there should be no issue in setting this as the current pattern match table.
Draft Release Note
$$set^%PATCODE can be used to load user defined pattern tables in UTF-8 mode. It returns 1 in case of a successful load. Previously it used to always return 0 in UTF-8 mode even if the integer codes (that satisfy a PATCODE) were < 128.
Final Release Note
Description
There are two means of loading user defined pattern tables.
I think this is a misfeature. Both schemes should be equivalent/consistent. The fact that a VIEW "PATLOAD" (which is always run implicitly or explicitly before the $$set^%PATCODE) succeeded means there was no integer code > 127 and if so there should be no issue in setting this as the current pattern match table.
Draft Release Note
$$set^%PATCODE can be used to load user defined pattern tables in UTF-8 mode. It returns 1 in case of a successful load. Previously it used to always return 0 in UTF-8 mode even if the integer codes (that satisfy a PATCODE) were < 128.