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 -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general