SV: OK, that's one LOCALE bug report too many...

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