Re: Do we still need MULE_INTERNAL?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Do we still need MULE_INTERNAL?
Date: 2026-03-31 21:34:28
Message-ID: a99a7ccc88e2939b047845230a55fe02528b4e7c.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2026-02-12 at 03:06 +1300, Thomas Munro wrote:
> On Wed, Feb 11, 2026 at 7:52 PM Tatsuo Ishii <ishii(at)postgresql(dot)org>
> wrote:
> > Thank you for the report. I find it is quite useful, especially the
> > Emacs 23 internal (new to me). I agree that MULE_INTERNAL has
> > fulfilled its historic role.
>
> Thanks Ishii-san and Tom.  Here's a patch.  Obviously it mostly just
> deletes thousands of lines, but also: I had to preserve the encoding
> number, so there's a hole in the table, 

pg_upgrade fails:

Performing Upgrade
------------------
...
Setting frozenxid and minmxid counters in new cluster
connection to server on socket "/.../.s.PGSQL.50432" failed: FATAL:
invalid database encoding: 7

You should have an explicit check.

Other than that, it looks good to me.

> and I had to think of a new
> name for cyrillic_and_mic.c, so I went with cyrillic.c because it
> handles 4 single-byte encodings and it wasn't clear how to fit into
> the existing x_and_y pattern (ie which two to highlight arbitrarily
> in
> the name).

Seems fine.

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Roberto Mello 2026-03-31 21:54:51 Re: pg_publication_tables: return NULL attnames when no column list is specified
Previous Message Heikki Linnakangas 2026-03-31 21:25:44 Re: Shared hash table allocations