Re: Do we still need MULE_INTERNAL?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-10T23:08:38Z
Lists: pgsql-hackers
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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pg_upgrade: Check for unsupported encodings.
- ce11e63f812f 19 (unreleased) landed
-
Remove MULE_INTERNAL encoding.
- 77645d44e355 19 (unreleased) landed