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