Re: adjust chr()/ascii() to prevent invalidly encoded data

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: adjust chr()/ascii() to prevent invalidly encoded data
Date: 2007-09-21 02:02:12
Message-ID: 18664.1190340132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Hmm, is this what we had agreed? I'm not sure I like it; if I'm using
> chr() to produce characters, then the application is going to have to
> worry about server_encoding in order to find the correct parameter to
> pass to chr().

That's always been the case.

> What I thought was the idea is that chr() always gets an Unicode code
> point, and it converts the character to the server_encoding.

I think that would be too big a break from past practice --- the
operative word being "break", because in LATINn character sets chr/ascii
work just fine.

I wouldn't object to introducing some sort of unicode_chr/unicode_ascii
function pair that translates to/from Unicode code points regardless of
the DB encoding. But that smells way more like a new feature than
plugging a hole, so I suggest it should wait for 8.4.

regards, tom lane

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message ITAGAKI Takahiro 2007-09-21 02:05:47 ecpg PREPARE is not thread safe
Previous Message Joshua D. Drake 2007-09-21 01:27:57 Re: [PATCHES] Patch to update log levels