diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 2b4fe0cb59..c867ea13de 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -5968,6 +5968,88 @@ SELECT regexp_match('abc01234xyz', '(?:(.*?)(\d+)(.*)){1,1}');
+
+ Differences with <literal>LIKE_REGEX</literal>
+
+
+ The LIKE_REGEX operator is specified starting with
+ the SQL:2008 standard to provide a more robust specification for
+ comparisons using regular expressions. Several other parts of the SQL
+ standard refer to the LIKE_REGEX specification
+ to define similar operations, including the
+ SQL/JSON path
+ like_regex filter.
+
+
+ The SQL standard states that regular expressions are evaluated according to
+ the XQuery standard for regular expressions. While POSIX regular
+ expressions are similar to XQuery regular expressions, there exist some
+ differences where the behavior deviates from what is defined for
+ LIKE_REGEX. Notably, regular expressions evaluated for
+ LIKE_REGEX are defined to work on Unicode encoded strings,
+ whereas POSIX regular expressions can work on strings of any encoding.
+
+
+ Other differences include:
+
+
+
+ Character class subtraction is not supported (for example, using the
+ following to search for only consonants:
+ [a-z-[aeiou]]).
+
+
+
+
+ The LIKE_REGEX specification states that a single
+ . should match a Windows newline
+ (\r\n) whereas POSIX will treat those as two separate
+ characters.
+
+
+
+
+ The format #NN where NN
+ represents two hex digits used for character class elements is not
+ supported. The same character class elements can be used with POSIX by
+ specifying \xNN.
+
+
+
+
+ Character class elements using \p{UnicodeProperty}
+ or the inverse \P{UnicodeProperty} are not supported.
+
+
+
+
+ Character class shorthands \i,
+ \I, \c, and \C
+ are not supported.
+
+
+
+
+ The specification for LIKE_REGEX may allow for more
+ characters for the \w character class shorthand, and
+ by extensions, excludes more characters with the complement
+ \W. As PostgreSQL depends on the underlying system's
+ locale, this may cause the behavior of \w and
+ \W to be equivalent to what POSIX provides.
+
+
+
+
+ The x flag in PostgreSQL extends on the specification
+ for LIKE_REGEX by allowing for comments specified
+ with #.
+
+
+
+
+
+
+
@@ -11872,6 +11954,38 @@ table2-mapping
+
+ Regular Expressions
+
+
+ SQL/JSON path expressions support the ability to match text using regular
+ expressions with the like_regex filter. For example,
+ the following SQL/JSON path query would case-insensitively match all
+ strings in an array that start with a vowel:
+
+'$[*] ? (@ like_regex "^[aeiou]" flag "i")'
+
+
+
+
+ The SQL/JSON standard borrows its definition for regular expressions
+ from the LIKE_REGEX operator, which in turns uses the
+ XQuery standard. PostgreSQL does not support the
+ LIKE_REGEX operator as it currently implements
+ POSIX regular expressions.
+
+
+
+ For its implementation of the SQL/JSON path like_regex
+ filter, PostgreSQL uses its POSIX implementation to evaluate the
+ regular expressions. While similar to the SQL standard specification for
+ the LIKE_REGEX operator, there are some noted
+ differences that you can read about in
+ .
+
+
+
+
SQL/JSON Path Operators and Methods
@@ -12114,9 +12228,10 @@ table2-mapping
like_regex
Tests pattern matching with POSIX regular expressions
- (see ). Supported flags
- are i, s, m,
- x, and q.
+ (see for additional
+ details). Supported flags are i,
+ s, m,
+ and q.
["abc", "abd", "aBdC", "abdacb", "babc"]$[*] ? (@ like_regex "^ab.*c" flag "i")"abc", "aBdC", "abdacb"