From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mark Dilger <pgsql(at)markdilger(dot)com>, Albe Laurenz <all(at)adv(dot)magwien(dot)gv(dot)at>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug in UTF8-Validation Code? |
Date: | 2007-04-04 06:01:56 |
Message-ID: | 20070404060156.GA22542@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 03, 2007 at 01:06:38PM -0400, Tom Lane wrote:
> I think it's probably defensible for non-Unicode encodings. To do
> otherwise would require (a) figuring out what the equivalent concept to
> "code point" is for each encoding, and (b) having a separate code path
> for each encoding to perform the mapping. It's not clear that there
> even is an answer to (a), and (b) seems like more work than chr() is
> worth. But we know what the right way is for Unicode, so we should
> special case that one.
I dunno. I find it odd that if I want a pl/pgsql function to return a
Euro symbol, it has to know what encoding the DB is in. Though I
suppose that would call for a unicode_chr() function.
Is there any multibyte mapping other than unicode that distinguishes
between the character set and the encoding thereof?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Albe Laurenz | 2007-04-04 07:40:02 | Re: Bug in UTF8-Validation Code? |
Previous Message | Jaime Casanova | 2007-04-04 04:55:59 | Re: Re: [HACKERS] [COMMITTERS] pgsql: Add GUC temp_tablespaces to provide a default location for |