Tim Allen writes:
> For converting, say, utf8 to euc-jp, it would be nice to be able to make
> use of all the existing infrastructure that PostgreSQL has for type
> conversion and type identification.
Unfortunately, that infrastructure is rather poorly suited for handling
arbitrary types.
> It'd be even nicer if you could make a table that has, say, one column
> utf8 (or utf32 even), one column euc-jp and one column shift-jis, so
> that you could cache format conversions.
This might be a nice thing to show off but I'm not sure about the
practical use. There's Unicode that you can use if you want to mix and
match on the server, and the ability to convert the character set between
client and server so the right thing shows up on everyone's screen.
> Under my grand plan one would have to implement comparison operators for
> each data type (as well as all the other things one has to implement for a
> data type);
You do realize that this would be hundreds, if not thousands, of things?
> BTW, how does postgres store multibyte text? As char * with a multibyte
> encoding?
Yes.
> As 16 bit or 32 bit code points? I should of course just look at
> the code and find out...:) I guess the former, from Peter's earlier
> comments. It does seem to me that using an explicit 32 bit representation
> (or at least providing that as an option) would make life easier in many
> ways.
I think the storage size penality would be prohibitive.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter