On Tue, Nov 23, 2010 at 5:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> And, after you've hacked your way through all that, you still end up
> with case-folding behavior that depends on the prevailing locale.
> Which is dangerous for the previously cited reasons, and arguably not
> spec-compliant.
>
So I thought the problem with the Turkish locale definition was that
it redefined how a capital ascii character which was present in
standard SQL identifiers was lowercased. Resulting in standard SQL
syntax not working.
I'm not sure I understand the danger if a user creates an object in a
database with a particular encoding and locale using that locale for
downcasing in the future. We don't currently support changing the
locale of a database or using different locales in the future. Even
with Peter's patch I think we can reasonably require the user to
specify a single locale which controls how the SQL identifiers are
interpreted regardless of the collations used in the operations.
The points about the C API being limited and nonportable are a
different issue.I guess I would need to do research to see if we're
missing something which would help here. Otherwise I might be
beginning to see the value in that /other/ library which I've argued
against in the past.
--
greg