Barry Lind writes:
> The reason for this is that in the en_US locale all non-alphanumeric
> characters are ignored when doing string comparisons. So the data above
> gets treated as:
> abc.xyz = abcxyz = abc/xyz (as the non-alphanumeric characters of '.'
> and '/' are ignored). This implys tha
In researching a problem I have uncovered the following bug in index
scans when Locale support is enabled.
Given a 7.0.3 postgres installation built with Locale support enabled
and a default US RedHat 7.0 Linux installation (meaning that the LANG
environment variable is set to en_US) to enable t
Barry Lind <[EMAIL PROTECTED]> writes:
> Now the real problem comes in when either the like or regex operators
> are used in a sql statement.
Right. As of 7.1beta1 we are dealing with this by suppressing LIKE/regex
index optimization in all locales other than "C". That's a pretty crude
answer b
