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

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)

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

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.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services