From: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
---|---|
To: | ZEUGSWETTER Andreas IZ5 <Andreas(dot)Zeugswetter(at)telecom(dot)at> |
Cc: | "'Oleg Bartunov'" <oleg(at)sai(dot)msu(dot)su>, "'hackers(at)postgresql(dot)org'" <hackers(at)postgreSQL(dot)org> |
Subject: | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Date: | 1999-06-10 01:37:00 |
Message-ID: | 375F16BC.ACDE874F@alumni.caltech.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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(at)alumni(dot)caltech(dot)edu
South Pasadena, California
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Robinson | 1999-06-10 02:14:10 | Re: [HACKERS] Postgres 6.5 beta2 and beta3 problem |
Previous Message | Bruce Momjian | 1999-06-10 01:13:34 | Re: [HACKERS] UNION + GROUP BY bug located |