Jasen Betts wrote:
> On 2011-04-22, Geoffrey Myers <geof@serioustechnology.com> wrote:
>> Vick Khera wrote:
>>> On Fri, Apr 22, 2011 at 11:00 AM, Geoffrey Myers
>>> <lists@serioustechnology.com <mailto:lists@serioustechnology.com>> wrote:
>>>
>>> Here's our problem. We planned on moving databases a few at a time.
>>> Problem is, there is a process that pushes data from one database to
>>> another. If this process attempts to push data from a SQL_ASCII
>>> database to a new UTF8 database and it has one of these characters
>>> mentioned above, the process fails.
>>>
>>>
>>> The database's enforcement of the encoding should be the last layer that
>>> does so. Your applications should be enforcing strict utf-8 encoding
>>> from start to finish. Once this is done, and the old data already in
>>> the DB is properly encoded as utf-8, then there should be no problems
>>> switching on the utf-8 encoding in postgres to get that final layer of
>>> verification.
>> Totally agree. Still, the question remains, why not leave it as SQL_ASCII?
>
> perhaps you want sorted output in some locale other than 'C'?
> or maybe want to take a substring in the database...
>
> utf8 in SQL-ASCII is just a string of octets
>
> utf8 in a utf8 database is a string of unicode characters.
We finally have a solution in place. A bug in my code was making the
problem bigger then it really is. Gotta love those bugs.
--
Until later, Geoffrey
"I predict future happiness for America if they can prevent
the government from wasting the labors of the people under
the pretense of taking care of them."
- Thomas Jefferson
