Tom Lane <tgl@sss.pgh.pa.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
referencefor 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
overwhelmingmajority 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
mostpragmatic. In the East Asia that I know and love, multibyte support, as a rule, is an ugly hack on top of
unibytetools and infrastructure. The exception is end-to-end Unicode systems, which can be relied on to produce
predictabledata. However, I've never encountered a native Simplified Chinese GB application in which it was the
leastbit 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
acceptedby all other tools in the work environment, and will stick with a unibyte build as long as this is the case.
-Michael Robinson
