GeezerVison

With Dialect.POSTGRESQL, StringValue.getNotExcapedValue resolves the \uXXXX and \UXXXXXXXX escapes of an E'...' string with Integer.parseInt and StringBuilder.appendCodePoint, with no range or surrogate check, while the U&'...' path added in #2820 already validates the same escapes the way the server does. So E'\uD800' comes back as a lone surrogate (an ill-formed string that turns into U+FFFD or '?' once it is encoded), E'\u0000' yields a NUL the server refuses, E'\U00110000' throws from StringBuilder, E'\UFFFFFFFF' throws NumberFormatException, and the parser accepts every one of them. I noticed it while comparing the two decoders after the U&'' change. The E'' Unicode escapes now go through the same code point and surrogate pair rules as the U&'' escapes: a pair must be two consecutive escapes, in either form, and too few digits, code point zero, anything above U+10FFFF and an unpaired surrogate raise the documented IllegalArgumentException. stringValue() in the grammar checks an escape string under the PostgreSQL dialect the way lexUnicodeEscapeString does for U&'' strings, so such a literal is a parse error as on the server. Standard strings and the other dialects are unchanged, and the regression test in StringValueTest covers the accepted and rejected forms.