Re: proposal: unescape_text function

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: David Steele <david@pgmasters.net>, Asif Rehman <asifr.rehman@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-29T10:22:28Z
Lists: pgsql-hackers
po 29. 3. 2021 v 12:19 odesílatel Peter Eisentraut <
peter.eisentraut@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

Commits

  1. Add unistr function