Sender: lockhart@hub.org
Message-ID: <375F16BC.ACDE874F@alumni.caltech.edu>
Date: Thu, 10 Jun 1999 01:37:00 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
MIME-Version: 1.0
To: ZEUGSWETTER Andreas IZ5 <Andreas.Zeugswetter@telecom.at>
CC: "'Oleg Bartunov'" <oleg@sai.msu.su>,
	"'hackers@postgresql.org'" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem
References: 
 <219F68D65015D011A8E000006F8590C60267B396@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Actually the SQL standard has something to say about national char
> and varchar. I think it is wrong that char and varchar change their 
> behavior in postgresql, if you enable locale. A locale sensitive column 
> needs to be specified as such in the create table statement according to 
> the standard. I never enable locale.

I had some discussions on the list a while ago (6 months?) about this
topic, but never really got feedback from "locale-using" people that
NATIONAL CHARACTER and collation sequences are an acceptable solution.
istm that Postgres' extensibility would make this *very* easy to
implement and extend, and that then everyone would get the same
behavior from CHAR while being able to get the behaviors they need
from a variety of other character sets.

I do have an interest in implementing or helping with something, but
since I don't have to live with the consequences of the results
(coming from an ASCII country :) it seemed to be poor form to push it
without feedback from others...

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California