Operators

GaussDB is compatible with most MySQL operators, but there are some differences. Unless otherwise specified, the operator behavior in B-compatible mode is the native GaussDB behavior by default.

**Table 1** Operators
MySQL	GaussDB	Difference
NULL-safe equal (<=>)	Supported.	-
[NOT] REGEXP	Supported, with differences	If the GUC parameter b_format_dev_version is set to 's2' and a pattern string with escape characters such as "\\a", "\\d", "\\e", "\\n", "\\Z", or "\\u" is matched with source character strings "\a", "\d", "\e", "\n", "\Z", or "\u", the behavior of GaussDB is different from that of MySQL 5.7 but the same as that of MySQL 8.0. When the GUC parameter b_format_dev_version is set to 's2', "\b" in GaussDB can match "\\b", but the matching will fail in MySQL. If the input parameter of the pattern string is invalid with only the right parenthesis ()), GaussDB and MySQL 5.7 will report an error, but MySQL 8.0 will not. In the rule of matching the de\|abc sequence with de or abc, when there are empty values on the left and right of the pipe symbol (\|), MySQL 5.7 will report an error, but GaussDB and MySQL 8.0 will not. The regular expression of the tab character "\t" can match the character class [:blank:] in GaussDB and MySQL 8.0 but cannot in MySQL 5.7. 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,}? {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 will be converted to the bytea type. However, the REGEXP operator does not support the bytea type. Therefore, the matching will fail.
[NOT] RLIKE	Supported, with differences	Same as [NOT] REGEXP.