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.
Date: Mon, 11 Mar 2024 16:21:52 -0400
Message-ID: <1548559.1710188512@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql@j-davis.com, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Catalog changes preparing for builtin collation provider.
In-Reply-To: <1548559.1710188512@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox