Peter Eisentraut <peter_e@gmx.net> writes:
> I don't understand why you call this a hack. Pattern matching and string
> comparison simply work differently, so the proper solution is to use
> different operator classes. After all, that's what operator classes exist
> for. What is left to be desired?
I think that a more general solution would be the ability to select a
locale (and hence a sort order) per-column, as the SQL spec envisions.
Then you'd just select C locale for columns you wanted to do pattern
matching for.
Admittedly, you'd still need the opclass-based approach for cases where
you wanted both pattern matching and a non-C-locale sort order ... but
I doubt that constitutes the majority of cases.
I guess my main concern is that we should not feel that this approach
takes the heat off us to support multiple locales. As a solution to the
narrow problem of LIKE performance, it's okay --- but it's not getting
us any nearer to a solution to the general locale problem.
regards, tom lane