Re: pgsql: Catalog changes preparing for builtin collation provider.

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: pgsql: Catalog changes preparing for builtin collation provider.
Дата
Msg-id 0ef325fa06e7a1605c4e119c4ecb637c67e5fb4e.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: pgsql: Catalog changes preparing for builtin collation provider.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pgsql: Catalog changes preparing for builtin collation provider.  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pgsql: Catalog changes preparing for builtin collation provider.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-committers
On Sun, 2024-03-10 at 00:05 -0500, Tom Lane wrote:
> Yeah.  It looks to me like it's somehow Perl-version-related.

I found it. On perl 5.16.3 on a failing instance:

   use strict;
   die '"" does not match qr// before substitution' unless '' =~ qr//;
   my $foo = ('|a|' =~ s/a//r);
   die '"" does not match qr// after substitution' unless '' =~ qr//;
   print "$foo\n";

dies with:

   "" does not match qr// after substitution at - line 4.

My commit adds a line using the s/// operator.

That's so bizarre that I have to guess that it's a perl bug. I poked
around in the perl docs to see if I'm missing something, but I didn't
find anything indicating that a substitution would have crazy side
effects. Please correct me if I'm wrong; I'm far from a perl expert.

Assuming that it is a perl bug, there are two potential workarounds:

1. Use qr/^$/ for the test rather than qr//.

2. Don't use s/// anywhere. Find another way to transform devel
versions into numbers.

Either one has the potential to leave traps for later. New tests might
either rely on s/// or expect qr// to work. I am inclined toward #1,
because if we use qr/^$/, other tests are likely to copy it and they
will be safe as well.

Though I'm still not sure what's going on with longfin.

Thoughts?

Regards,
    Jeff Davis




В списке pgsql-committers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: pgsql: Remove unneeded vacuum_delay_point from heap_vac_scan_get_next_b
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgsql: Catalog changes preparing for builtin collation provider.