Re: TODO: Expose parser support for decoding unicode escape literals to user

On 05/16/2014 04:12 AM, Craig Ringer wrote:
> On 05/15/2014 09:56 PM, Adrian Klaver wrote:
>>
>> test=> SELECT quote_literal(E'test \u011B');
>>   quote_literal
>> ---------------
>>   'test ě'
>
> That's another case where the function isn't doing what you expect.
> quote_literal has nothing to do with what's happening, it's
> escape-string processing in the parser doing the work. Compare:
>
> regress=> SELECT 'test \u011B';
>    ?column?
> -------------
>   test \u011B
> (1 row)
>
> regress=> SELECT E'test \u011B';
>   ?column?
> ----------
>   test ě
> (1 row)

Davids comments and some playing around with strings showed me what was
going on and the error of my ways.

>
> now, the problem posed is if you had this:
>
> regress=> CREATE TABLE test AS SELECT TEXT 'test \u011B' dummy;
> SELECT 1
> regress=> SELECT * FROM test;
>      dummy
> -------------
>   test \u011B
> (1 row)
>
> how would you get 'test ě' ?
>
>
> The parser can do it, but I don't think anyone would consider this an
> acceptable solution to this problem (anybody reading this, UNDER NO
> CIRCUMSTANCES USE THIS FUNCTION, EVER):
>
>
> regress=> CREATE OR REPLACE FUNCTION ohmygod(text) RETURNS text AS $$
> DECLARE
>      retval text;
> BEGIN
>      -- If you use this in real code, I hate you
>      EXECUTE 'SELECT E'''||$1||''';' INTO retval;
>      RETURN retval;
> END;
> $$ LANGUAGE plpgsql;
> CREATE FUNCTION


Actually I started down this dark path also, before I was interrupted by
something else:)

>
> regress=> SELECT ohmygod(dummy) FROM test;
>   ohmygod
> ---------
>   test ě
> (1 row)
>
>
>
> It'd be nice to expose this capability to users without requiring that
> kind of horror.
>
> Hence: exposing parser support for decoding unicode escape literals to
> the user.

Yes, so as an example something like:

decode_u('test \u011B')

that would decode the escaped values automatically.

>


--
Adrian Klaver
adrian.klaver@aklaver.com