po 29. 3. 2021 v 12:19 odesÃlatel Peter Eisentraut < peter.eisentr...@enterprisedb.com> napsal:
> 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. > Thank you very much Pavel
