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
