On Tue, Nov 23, 2010 at 5:12 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
