From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, 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 14:22:28 |
Message-ID: | 21381.1175696548@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Right -- IMHO what we should be doing is reject any input to chr() which
> is beyond plain ASCII (or maybe > 255), and create a separate function
> (unicode_char() sounds good) to get an Unicode character from a code
> point, converted to the local client_encoding per conversion_procs.
Hm, I hadn't thought of that approach, but another idea is that the
argument of chr() is *always* a unicode code point, and it converts
to the current encoding. Do we really need a separate function?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-04 14:31:29 | Re: Vacuum in multi-statement |
Previous Message | Markus Schiltknecht | 2007-04-04 14:21:29 | Re: Auto Partitioning |