From: | "Albe Laurenz" <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
---|---|
To: | "Andrew Dunstan *EXTERN*" <andrew(at)dunslane(dot)net> |
Cc: | "Tom Lane *EXTERN*" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: invalidly encoded strings |
Date: | 2007-09-11 07:41:34 |
Message-ID: | D960CB61B694CF459DCFB4B0128514C22FBDA1@exadv11.host.magwien.gv.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan wrote:
>> Instead of the code point, I'd prefer the actual encoding of
>> the character as argument to chr() and return value of ascii().
>
> And frankly, I don't know how to do it sanely anyway. A character
> encoding has a fixed byte pattern, but a given byte pattern
> doesn't have
> a single universal number value. I really don't think we want to have
> the value of chr(n) depend on the endianness of the machine, do we?
>
> The reason we are prepared to make an exception for Unicode
> is precisely because the code point maps to an encoding
> pattern independently of architecture, ISTM.
Point taken.
I only wanted to make sure that there are good reasons to
differ from Oracle.
Oracle's chr() is big-endian on all platforms, BTW.
Yours,
Laurenz Albe
From | Date | Subject | |
---|---|---|---|
Next Message | Zdenek Kotala | 2007-09-11 09:07:21 | Re: Per-function search_path => per-function GUC settings |
Previous Message | Oleg Bartunov | 2007-09-11 07:19:51 | Re: Ts_rank internals |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-09-11 07:47:41 | Re: HOT patch - version 15 |
Previous Message | Tatsuo Ishii | 2007-09-11 07:17:06 | Re: invalidly encoded strings |