Fix LP Bug 1382686 - LIKE predicate fails on some UTF8 columns The description of this LP bug says that the LIKE predicate fails when the pattern string starts with a '%' and when selecting from a view, but not when selecting from the underlying table. However, in the supplied reproducible test case, the view's column had a character set of UTF8 while the underlying table had a character set of UCS2.
As it turns out, the real problem is not related to selecting from a view. The root cause is a bug in the PCODE implementation for the LIKE predicate and this problem can occur any time the LIKE predicate is applied to a column declared as VARCHAR(nnn) CHARACTER SET UTF8 where 128 <= nnn <= 255... and the problem may not be limited to situations where the LIKE pattern starts with a '%'.
When nnn > 255, the PCODE implmentation is not used, so the problem does not occur then.
The root cause is a place in the code where the length of the column (in characters, not bytes) is stored in a single byte and is retrieved as if that byte contains a *signed* value. When 128 <= nnn <= 255, that retrieval results in a negative value. The fix is to retrieve the value as an *unsigned* value.
NOTE: This commit changes 2 lines of code. The second line changed is the only one necessary to fix the problem. The first line is being changed as well because it has a similar problem and would prevent the LIKE predicate from working properly if the LIKE pattern had more than 127 pattern parts.
metadata fixes and 'sqlmp' code cleanup -- NATable struct for metadata was being created multiple times whenever information for a new table was read from metadata. That has been fixed. -- an 'initialize trafodion, drop' followed by 'initialize traf' from the same session was failing due to priv info not getting reset. This would show up if 'initialize authorization' was done earlier. That has been fixed. -- code cleanup mostly related to sqlmp legacy code and reference.