On Mon, Oct 22, 2007 at 10:55:14AM -0400, Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
> > As I chatted with Dave about - wnat encoding? We pull that value cluster
> > wide, but the encoding is per-database. You could have one UTF8 and one
> > WIN1252 database...
> Will chklocale.c actually allow that? Should it? We've spent a lot of
> time zeroed in on initdb's behavior, but the other piece of the puzzle
> is which DB encodings should CREATE DATABASE allow afterwards. It
> sounds to me that Windows may be more flexible than the standard Unix
> locale support on this point, but I'm not sure how much more flexible.
Yes, if I pick the proper locale, it does work.
FOr example, I can properly initdb in UTF8 and then create a WIN1252
> There's also the question of how we make sure that strings returned
> by the OS (eg strerror) are in the DB's encoding. I think that the
> Unix side is not fully up to speed on that either --- we don't try
> to prevent you from setting, eg, LC_MESSAGES = foo.utf8 when LC_CTYPE
> and the DB encoding are iso88591. I've thought about trying to enforce
> that the encoding-suffix-if-any is the same as LC_CTYPE's for all the LC_
> values, but I'm not sure whether that approach is sane for Windows.
That's a potential problem - I assume you'll have the same problem as on
Unix if you say your db is in UTF8 buy your messages are in LATIN1.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not