Jeff Davis writes:
> Patch attached, following the example in AdjustUpgrade.pm. It feels a
> bit inconsistent to sometimes use $oldnode->pg_version and sometimes
> use $old_major_version, but it's certainly better than what I had done
> in f696c0cd5f.
You're still doing it the hard way. I sugges
On Mon, 2024-03-11 at 18:04 -0400, Tom Lane wrote:
> Another question is why it didn't fail on all the animals with
> similar
> Perl vintage. My guess about that is that there's some configuration
> difference causing the Perl script to take slightly different code
> paths, but it's just a guess.
On Mon, 2024-03-11 at 17:08 -0400, Tom Lane wrote:
> Jeff Davis writes:
>
> was perfectly correct as it stood, because pg_version is a
> PostgreSQL::Version object. Why did you feel a need to
> editorialize on that?
The goal was to do a version check for 17 that's inclusive of
development versi
Jeff Davis writes:
> I am still confused on a couple of points here, such as: why does my
> example work fine on newer versions of perl?
I'm not sure about that either. The discussions of this that I found
on-line say that it's not something the Perl gurus want to get rid of,
but it sure seems l
On Mon, 2024-03-11 at 16:21 -0400, Tom Lane wrote:
> Oh! No, it's a "feature": man perlop quoth
Wow.
> So we actually need to find and nuke all of these, not just the one
> that's causing trouble.
For now I committed the one change to fix the buildfarm.
I am still confused on a couple of point
Jeff Davis writes:
> My commit adds a line using the s/// operator.
Oh, independently of the empty-pattern problem: what you added is
+# Numeric major version of old cluster, ignoring "devel" suffix.
+# Needed for testing upgrades from development version to itself.
+my $old_major_version = int(
I wrote:
> Jeff Davis 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 ex
Jeff Davis writes:
> 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 wit
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 '"" doe
Jeff Davis writes:
> On Sat, 2024-03-09 at 22:50 +, Jeff Davis wrote:
>> Catalog changes preparing for builtin collation provider.
> This is causing problems on a couple buildfarm members (mantid,
> lapwing, snakefly) that all look like this:
> ...
> That's a little confusing to me: the '(?^:
On Sat, 2024-03-09 at 22:50 +, Jeff Davis wrote:
> Catalog changes preparing for builtin collation provider.
This is causing problems on a couple buildfarm members (mantid,
lapwing, snakefly) that all look like this:
# Running: pg_upgrade --no-sync -d
/home/postgres/buildroot/HEAD/pgsql.build
Catalog changes preparing for builtin collation provider.
Rename pg_collation.colliculocale to colllocale, and
pg_database.daticulocale to datlocale. These names reflects that the
fields will be useful for the upcoming builtin provider as well, not
just for ICU.
This is purely a rename; no change
12 matches
Mail list logo
