Re: Ready for beta2?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Dave Page <dpage(at)postgresql(dot)org>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ready for beta2?
Date: 2007-10-22 14:55:14
Message-ID: 6578.1193064914@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> 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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-10-22 15:00:24 Re: MVCC, undo log, and HOT
Previous Message Trevor Talbot 2007-10-22 14:43:35 Re: 8.2.3: Server crashes on Windows using Eclipse/Junit