Operators

GaussDB is compatible with most MySQL operators, but there are some differences. If not listed, the operator behavior is the native GaussDB behavior by default.

**Table 1** Operator
No.	MySQL	GaussDB	Difference
1	NULL-safe equal (<=>)	Supported.	-
2	[NOT] REGEXP	Supported.	When b_format_dev_version is set to 's2', the pattern string contains escape characters such as '\\a', '\\d', '\\e', '\\n', '\\Z', and '\\u', and the source strings '\a', '\d', '\e', '\n', '\Z', and '\u' are matched, the behavior of GaussDB is different from that of MySQL 5.7. MySQL 5.7 has a bug, which has been fixed in later MySQL versions and is now consistent with GaussDB. When b_format_dev_version is set to 's2', GaussDB's '\b' can match '\\b', but MySQL cannot. GaussDB reports an error when the input parameter of the pattern string pat is invalid and only the right single parenthesis ')' exists. MySQL has a bug, which has been fixed in later versions. When de\|abc matches de or abc, if there is a null value on the left or right of \|, MySQL reports an error. This bug has been fixed in later versions. The regular expression of the blank character [\t] can match the character class [:blank:] in GaussDB, but MySQL's [\t] cannot match [:blank:]. MySQL has a bug, which has been fixed in later versions. GaussDB supports non-greedy pattern matching. That is, the number of matching characters is as small as possible. A question mark (?) is added after some special characters, for example, ??, *?, +?, {n}?, {n,}?, and {n,m}?. MySQL 5.7 does not support non-greedy pattern matching, and the error message "Got error 'repetition-operator operand invalid' from regexp" is displayed. MySQL 8.0 already supports this function. In the binary character set, the text and BLOB types are converted to the bytea type. The REGEXP operator does not support the bytea type. Therefore, the two types cannot be matched.
3	[NOT] RLIKE	Supported.	Same as [NOT] REGEXP.