On 25.03.21 10:44, Peter Eisentraut wrote:
On 10.03.21 14:52, David Steele wrote:
I thought about it a little bit more, and the prefix specification
has not too much sense (more if we implement this functionality as
function "unistr"). I removed the optional argument and renamed the
function to "unistr". The functionality is the same. Now it supports
Oracle convention, Java and Python (for Python UXXXXXXXX) and
\+XXXXXX. These formats was already supported.The compatibility witth
Oracle is nice.
Peter, it looks like Pavel has aligned this function with unistr() as
you suggested. Thoughts?
I haven't read through the patch in detail yet, but I support the
proposed details of the functionality.
Committed.
I made two major changes: I moved the tests from unicode.sql to
strings.sql. The first file is for tests that only work in UTF8
encoding, which is not the case here. Also, I wasn't comfortable with
exposing little utility functions from the parser in an ad hoc way. So
I made local copies, which also allows us to make more
locally-appropriate error messages. I think there is some potential for
refactoring here (see also src/common/hex.c), but that's perhaps better
done separately and more comprehensively.
