From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Catalog changes preparing for builtin collation provider.
In-reply-to: <1547879.1710188139@sss.pgh.pa.us>
References: <E1rj5WA-002z5V-WA@gemulon.postgresql.org>
 <8899c7c62b86370076110920686fd24863b69a01.camel@j-davis.com>
 <1222780.1710047108@sss.pgh.pa.us>
 <0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.camel@j-davis.com>
 <1547879.1710188139@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Mon, 11 Mar 2024 16:15:39 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1548558.1710188512.1@sss.pgh.pa.us>
Date: Mon, 11 Mar 2024 16:21:52 -0400
Message-ID: <1548559.1710188512@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1548559.1710188512%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> That's so bizarre that I have to guess that it's a perl bug.

> I agree.

Oh!  No, it's a "feature": man perlop quoth

       The empty pattern "//"
               If the PATTERN evaluates to the empty string, the last
               successfully matched regular expression is used instead.  In
               this case, only the "g" and "c" flags on the empty pattern are
               honored; the other flags are taken from the original pattern.
               If no match has previously succeeded, this will (silently) act
               instead as a genuine empty pattern (which will always match).

So we actually need to find and nuke all of these, not just the one
that's causing trouble.

			regards, tom lane