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