From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
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-10 13:51:09 |
Message-ID: | 46E54BCD.30301@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Albe Laurenz wrote:
> I'd like to repeat my suggestion for chr() and ascii().
>
> Instead of the code point, I'd prefer the actual encoding of
> the character as argument to chr() and return value of ascii().
>
>
>
[snip]
> Of course, if it is generally perceived that the code point
> is more useful than the encoding, then Oracle compliance
> is probably secondary.
>
>
>
Last time this was discussed, you were the only person arguing for that
behaviour, IIRC.
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.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-10 13:56:10 | Re: invalidly encoded strings |
Previous Message | Simon Riggs | 2007-09-10 13:49:42 | Re: Include Lists for Text Search |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-09-10 13:56:10 | Re: invalidly encoded strings |
Previous Message | Simon Riggs | 2007-09-10 13:49:42 | Re: Include Lists for Text Search |