Re: [GENERAL] ascii() for utf8 - Mailing list pgsql-hackers

From Stuart McGraw
Subject Re: [GENERAL] ascii() for utf8
Date
Msg-id AKEFJAHAPDBEDKIICNJKIEMKCDAA.smcg2297@frii.com
Whole thread Raw
In response to Re: [GENERAL] ascii() for utf8  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
From: Alvaro Herrera
> Decibel! wrote:
> > Moving to -hackers.
> >
> > On Jul 27, 2007, at 1:22 PM, Stuart wrote:
> >> Does Postgresql have a function like ascii() that will
> >> return the unicode codepoint value for a utf8 character?
> >> (And symmetrically same for question chr() of course).
> 
> > I suspect that this is just a matter of no one scratching the itch. I 
> > suspect a patch would be accepted, or you could possibly put something on 
> > pgFoundry.
> 
> Nay; there were some discussions about this not long ago, and I think
> one conclusion you could draw from them is that many people want these
> functions in the backend.

That would certainly be my preference.  I will be distributing an 
application, the database part of which may (not sure yet) require 
this function, to multiple platforms including Windows and (though 
I have never done it) am anticipating it will be significantly harder 
if I have to worry about the recipient compiling an external function 
or making sure a dll goes in the right place, gets updated, etc.

> > I'd set it up so that ascii() and chr() act according to the 
> > appropriate locale setting (I'm not sure which one would be appropriate).
> 
> I don't see why any of them would react to the locale, but they surely
> must honor client encoding.

Wouldn't this be the database encoding?  (I have been using 
strictly utf-8 and admit I am pretty fuzzy on encoding issues.)

If one had written an external function, how much more effort 
would it be to make it acceptable for inclusion in the backend? 



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: GIT patch
Next
From: Alvaro Herrera
Date:
Subject: Re: GIT patch