Re: Multibyte still broken

> More robust code may always be good, but "good" apparently doesn't always go
> into the tree.  Imagine my surprise, while upgrading a production server
> from 6.5.3 to 7.0, when the data dumped from the old database failed to load
> into the new database (well, crashed the backend, to be specific).
> 
> Apparently the "validate your own damn data" sentiment of the first excerpt
> above has prevailed, because, on inspection, the MB code is just as fragile
> as it was five months ago.
> 
> I was forced to perform emergency repairs to my database dump file to fool a 
> non-multibyte 7.0 into accepting it.  Since EUC_CN is compatible with 
> Latin-1, and since the benefits of multibyte are small compared to the 
> risks, I intend to stick with unibyte Postgres henceforth.
> 
> I would, though, recommend a warning in the "INSTALL" file along the lines of:
> 
>   "WARNING: Use of improperly-encoded text with multi-byte support enabled
>    WILL lead to data corruption and/or loss.  Do not enable multi-byte support
>    unless you intend to fully validate your own damn data."

Sorry for the problem. I forgot about issue:-<

What I'm thinking now to fix the problem you found is that doing data
validataion in the text/var/char input functions, rather than tweaking
the mb functions. If corrupted MB string was found, then call
elog(ERROR) to abort the transation. Will appear in 7.0.1 unless
someone objects.
--
Tatsuo Ishii