* Greg Sabino Mullane: > Here's the latest proposed utf8 plan: > > On connection, we check if the database (server_encoding) > is SQL_ASCII. If it is, we do nothing. If it is not SQL_ASCII, > we check the client_encoding. If not UTF-8, we SET it so. > > We also check if the pg_enable_utf8 flag is set before the above. > If it is set to true, we ignore the SQL_ASCII check. If set to > false, we do not do the UTF-8 client_encoding SET. > > At this point, all we care about is if we are in utf8 mode, or > byte soup mode. If the former, we assume everything coming back > from the database is UTF-8 and mark it as such in the Perl strings. > If the latter, we do nothing special and never set strings to utf8. > How we get to the states:
As just one datapoint: this change will cause havoc in our systems. This might be rather unusual (and we we can certainly deal with it in some way), but I wonder if others will face similar problems. -- Florian Weimer <[email protected]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
