From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Do we still need MULE_INTERNAL?
In-reply-to: <CA+hUKGKXDXh-FdU0orjfv+F08f=D91BhV3Ra-4zL-q+JmGYqTA@mail.gmail.com>
References: <CA+hUKGKXDXh-FdU0orjfv+F08f=D91BhV3Ra-4zL-q+JmGYqTA@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Wed, 11 Feb 2026 11:39:20 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3980442.1770764918.1@sss.pgh.pa.us>
Date: Tue, 10 Feb 2026 18:08:38 -0500
Message-ID: <3980443.1770764918@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/3980443.1770764918%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> MULE_INTERNAL solved a really hard problem years ago and must have
> been extremely useful, but I think we might be able to drop it now,
> and I have a patch.

FWIW, I am on board with dropping it, and I have another reason
you didn't list: AFAICS there are multiple ways to represent the
same string in MULE.  Any character available in more than one
encoding has more than one equally-legitimate MULE representation,
which is catastrophic for functions as basic as text equality.
You could argue that this is no worse than the situation for
combining characters in Unicode, but there there's at least an
agreed-on normal form.

> This history may be very well known to hackers in Japan, but I had to
> start from zero with my archeologist hat on, and I suspect this is as
> obscure to many others as it was to me, so here's what I have come up
> with:

Thanks for doing that research, BTW.  This was mostly new to me.

			regards, tom lane