On 4/15/09, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Marko Kreen <mark...@gmail.com> writes:
> > As both this and the doubling-\\ way would mean we should have usable
> > alternative in case of stdstr=off also, so in the end we have agreed
> > to accept \u also?
>
> Given Martijn's complaint about more-than-16-bit code points, I think
> the \u proposal is not mature enough to go into 8.4. We can think
> about some version of that later, if there's enough interest.
I think it would be good idea. Basically we should pick one from
couple of pre-existing sane schemes. Here is quick summary
of Python, Perl and Java:
Python [1]:
\uXXXX - 16-bit codepoint
\UXXXXXXXX - 32-bit codepoint
\N{char-name} - Characted by name
Perl [2]:
\x{XXXX..} - {} contains hexadecimal codepoint
\N{char-name} - Unicode char name
Java [3]:
\uXXXX - 16-bit codepoint
Perl is OK, but the \x makes think of literal hex-decimal, and thats
because they have extented their literal byte-escapes to support unicode.
So I doubt we should promote it more. \u{} would be nicer, but that
would not be an established standard.
Both Python and Java allow using \u to encode higher codepoints with
surrogate pairs. Which sort of makes it standard and Python superset
of Java. (Obviously that does not mean you need to store them
as surrogate pairs.)
Problem with having only \u would be that this would make hard to enter
higher codepoints manually. So \U would also be good to have.
There is no hurry with \N{} but if it would be possible, it would be
main reason to have custom unicode escaping.
So my proposal would be Python escapes without \N{}.
Whether we should have it in 8.4, I don't know. If we will have U&,
but it does not work with stdstr=off, this seems to hint we should have
some other escaping method available in 8.4 for stdstd=off users?
--
marko
[1] http://docs.python.org/reference/lexical_analysis.html#string-literals
[2] http://perldoc.perl.org/perluniintro.html
[3] http://java.sun.com/docs/books/jls/third_edition/html/lexical.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
