From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Asif Rehman <asifr(dot)rehman(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: unescape_text function |
Date: | 2021-03-29 10:19:07 |
Message-ID: | 0ce45cbb-8590-31d8-f6e9-0e95ece98936@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2021-03-29 10:22:28 | Re: proposal: unescape_text function |
Previous Message | vignesh C | 2021-03-29 10:18:43 | Re: [PATCH] Provide more information to filter_prepare |