Martijn van Oosterhout <kleptog@xxxxxxxxx> writes:
> SQL_ASCII means that the database does no locale specific or language
> specific encoding ever. It won't check what you send it either. If
> you're content to let clients deal with any encoding issues, this may
> be what you want.
> But anything to do with lower(), upper(), case-insenstive in the
> database itself will be totally stupid since it's assuming ASCII.
Actually it's worse than that: case conversion and comparisons inside
the database will still be done using whatever locale setting the
database was initdb'd with. If that locale is C, then you have just
ASCII-aware case conversions and memcmp-like sorting, but everything
will behave reasonably sanely within those limitations. If the locale
is not C then it is assuming some specific encoding that *the database
is not enforcing*. This is bad news and can result in all sorts of
inconsistent behavior.
We really need to figure out some way of enforcing that the database
encoding is OK to use with the locale setting. Peter put some trial
code for this into initdb in 8.0, but it's only issuing a warning rather
than enforcing the restriction, so I don't have a lot of confidence
that it is right. (How many people even noticed the warning message?)
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
