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.
Re: pgsql: Catalog changes preparing for builtin collation provider. |
Список | 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 по дате отправления: