Re: Multibyte still broken

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>Sorry you had trouble,

Trouble I had foreseen, which I had brought to the mailing list, and for
which I had provided an explanation and fix, by the way.

>but the above seems uncalled-for. What would be
>more productive is a submitted patch to apply against 7.0.

Actually, I think there are three separate issues here.

1. There was a potentially serious problem, and it didn't get on Bruce's
master TODO list, which is the authoritative reference for what in Postgres
needs to be fixed. I take responsibility for not seeing to it that this
was done.

2. By its nature, the multi-byte code is poorly overseen, and poorly
exercised. This is understandable, as the overwhelming majority of
Postgres installations don't want or need it. However, the result is that
it's effectively a "contrib"-quality component in the Postgres core.

3. The multi-byte support, as it currently exists, is founded on a particular
philosophy, one which I argue is not the most pragmatic. In the East Asia
that I know and love, multibyte support, as a rule, is an ugly hack on top
of unibyte tools and infrastructure. The exception is end-to-end Unicode
systems, which can be relied on to produce predictable data. However, I've
never encountered a native Simplified Chinese GB application in which it
was the least bit difficult to produce "illegal" code sequences. In a
real-world environment, with email attachments, cut-and-paste, and whatnot,
it's practically inevitable.

Thus, I cannot accept a situation where my database aborts on, or
otherwise rejects data that is produced and accepted by all other tools
in the work environment, and will stick with a unibyte build as long as
this is the case.

-Michael Robinson