SV: OK, that's one LOCALE bug report too many...
От | Jarmo Paavilainen |
---|---|
Тема | SV: OK, that's one LOCALE bug report too many... |
Дата | |
Msg-id | 007601c0586c$efcd5f20$1501a8c0@theboss.comder.private обсуждение исходный текст |
Ответ на | Re: OK, that's one LOCALE bug report too many... (Karel Zak <zakkr@zf.jcu.cz>) |
Список | pgsql-hackers |
Hi, ... > LC_NUMERIC and LC_TIME ... > The timeofday() make output via strftime() if you set LC_ALL, a query > like: select timeofday()::timestamp; Actually *I would* expect it to return a localized string. But then again I always expect BE to use '.' as decimal point ( I must be damaged :-/ ). ... > We need *robust* BE<->FE correct and comumns specific local supporte, I agree :-) And the easiest (and only robust) way would be to define which char is decimal point, how a date/time must be formated to be accepted on a INSERT or SELECT. And leave the job of localization to the FE. (I do not know what SQL9_ says about this, and franctly I do not care.) And then to sorting (and compare) of strings. PostgreSQL should decide on one charset (UTF8, UTF16) and expect that clients (FE) to enforce that. Yes some sorting would be wrong but In most cases it would be correct. PostgreSQL will never be able to do correct indexing in a mized locale enviroment if it does not have one index tree (hash or whatever) per locale. But with UTF8 it could do a good (if not perfect) jobb. Something like this for sorting:noice-chars-in-any-order..0..1..A..a..e..é..E..È..U..Ü..u..ü..Z..z..Ö..ö And as time/date/timestamp format:2000.11.27 12:55.01.000000 would be a good compromize. This maybe feels like moving the trouble from BE to FE, but *I think* this is the only solution that would always work (if not perfectly...). And this would remove all the problems with the "--enable-locale which locale to use" problem. Also if someone would want to connect with a new unknown locale it would work without changes in the BE side. And to the errorious results from "SELECT * FROM myTable where strString > 'abc'". This suggestion would not solve all of those, but it would solve most of them. And *I think* any compare but = and != on a string is prone to errors (even as a optimation of LIKE). // Jarmo
В списке pgsql-hackers по дате отправления: