> Tatsuo Ishii kirjutas T, 21.10.2003 kell 12:07:
> > > Why cannot do PostgreSQL as 100% pure Unicode system? We can do
> > > conversion from/to others encodings as client/server communication
> > > extension, but internaly in BE we can use only pure Unicode data. I
> > > think
Tatsuo Ishii kirjutas T, 21.10.2003 kell 12:07:
> > Why cannot do PostgreSQL as 100% pure Unicode system? We can do
> > conversion from/to others encodings as client/server communication
> > extension, but internaly in BE we can use only pure Unicode data. I
> > think a lot of
> Why cannot do PostgreSQL as 100% pure Unicode system? We can do
> conversion from/to others encodings as client/server communication
> extension, but internaly in BE we can use only pure Unicode data. I
> think a lot of things will more simple...
Please don't do that. There'
Karel Zak kirjutas T, 21.10.2003 kell 10:50:
> On Mon, Oct 20, 2003 at 10:58:00PM +0200, Peter Eisentraut wrote:
>
> > (Note that I say Unicode a lot here because those people do a lot of
> > research and standardization in this area, which is available for free,
> > but this does not constrain th
On Mon, Oct 20, 2003 at 10:58:00PM +0200, Peter Eisentraut wrote:
> (Note that I say Unicode a lot here because those people do a lot of
> research and standardization in this area, which is available for free,
> but this does not constrain the result to work only with the Unicode
> character set.
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I agree that depending on the system-provided locale behavior has its
>> downsides, but it has its upsides too;
> I like to think that in the end we can do much better than the POSIX
> framework can do.
Sure, we can make it work e
Tom Lane writes:
> I'm not sure that "supporting our own locale subsystem" really qualifies
> as "sustainable" ... can you give an estimate of how big the code +
> supporting data is likely to be?
It's not much worse than supporting our own character conversion subsystem
(which, btw., is somethin
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> If we have to write our own locale
>> support it's likely to be a long time coming :-(
> Naturally, I cannot promise anything, but this is at the top of my list
> for the next release. I already have sorted out the specifications
Dennis Bjorklund <[EMAIL PROTECTED]> writes:
> On Mon, 20 Oct 2003, Tom Lane wrote:
>> I noticed by chance that glibc has a "reentrant locale" API that seems
>> to allow for efficient access to multiple locales concurrently.
> Where have you found this?
It's present in RH8 --- there is plus vari
Peter Eisentraut kirjutas E, 20.10.2003 kell 21:02:
> Tom Lane writes:
>
> > I noticed by chance that glibc has a "reentrant locale" API that seems
> > to allow for efficient access to multiple locales concurrently. Perhaps
> > it would be a reasonable solution to support multiple locales only on
Tom Lane writes:
> I noticed by chance that glibc has a "reentrant locale" API that seems
> to allow for efficient access to multiple locales concurrently. Perhaps
> it would be a reasonable solution to support multiple locales only on
> machines that have this library. If we have to write our o
On Mon, 20 Oct 2003, Tom Lane wrote:
> I noticed by chance that glibc has a "reentrant locale" API that seems
> to allow for efficient access to multiple locales concurrently.
Where have you found this?
I've been looking for that but have not found it. I run a rh9 system, do
you have something n
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tatsuo Ishii kirjutas E, 20.10.2003 kell 15:37:
>> There's absolutely no relationship between database encoding and
>> locale.
> How does the system then use locale for sorting and not for upper/lower
> ?
LC_COLLATE and LC_CTYPE are independent setting
Hannu Krosing <[EMAIL PROTECTED]> writes:
>> It's been suggested that we could use where available.
>> However there are a bunch of issues that would have to be solved to make
>> that happen. (How do we convert between the database character encoding
>> and the wctype representation?
> How do
Tatsuo Ishii kirjutas E, 20.10.2003 kell 15:37:
> > Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> > > Oliver Elphick <[EMAIL PROTECTED]> writes:
> > > > There is a bug in Unicode upper() which has been present since 7.2:
> > >
> > > We don't support upper/lower in multibyte character sets, and can
> Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> > Oliver Elphick <[EMAIL PROTECTED]> writes:
> > > There is a bug in Unicode upper() which has been present since 7.2:
> >
> > We don't support upper/lower in multibyte character sets, and can't as
> > long as the functionality is dependent on 's tou
Tom Lane kirjutas E, 20.10.2003 kell 03:35:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > There is a bug in Unicode upper() which has been present since 7.2:
>
> We don't support upper/lower in multibyte character sets, and can't as
> long as the functionality is dependent on 's toupper()/tolow
Oliver Elphick <[EMAIL PROTECTED]> writes:
> There is a bug in Unicode upper() which has been present since 7.2:
We don't support upper/lower in multibyte character sets, and can't as
long as the functionality is dependent on 's toupper()/tolower().
It's been suggested that we could use where ava
18 matches
Mail list logo
