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
