Re: Patch: add conversion from pg_wchar to multibyte

> So far as I can see, the only LCPRVn marker code that is actually in
> use right now is 0x9d --- there are no instances of 9a, 9b, or 9c
> that I can find.
>
> I also read in the xemacs internals doc, at
> http://www.xemacs.org/Documentation/21.5/html/internals_26.html#SEC145
> that XEmacs thinks the marker code for private single-byte charsets
> is 0x9e (only) and that for private multi-byte charsets is 0x9f (only);
> moreover they think 0x9a-0x9d are potential future official multibyte
> charset codes. I don't know how we got to the current state of using
> 0x9a-0x9d as private charset markers, but it seems pretty inconsistent
> with XEmacs.

At the time when mule internal code was introduced to PostgreSQL,
xemacs did not have multi encoding capabilty and mule (a patch to
emacs) was the only implementation allowed to use multi encoding. So I
used the specification of mule documented in the URL I wrote.

> Since only 0x9d could possibly be on-disk anywhere at the moment (unless
> I'm missing something), I think we would be well advised to redefine our
> marker codes thus:
>
> LCPRV1 0x9e (only) (matches XEmacs spec)
> LCPRV2 0x9d (only) (doesn't match XEmacs, but too late to change)
>
> This would simplify and speed up the IS_LCPRVn macros, simplify the
> conversions that Alexander is worried about, and get us out from under
> the risk that XEmacs will assign their next three official multibyte
> encoding IDs. We're still in trouble if they ever get to 0x9d, but
> since that's the last code they have, I bet they will be in no hurry
> to use it up.
>
> regards, tom lane