column size with precision handling is broken when using DBD::Pg 3.19

[ugexe]

We recently had a test that does a schema diff start failing after updating to DBD::Pg 3.19. I don't have a golf and can't give you the full error output, but the failures essentially look like this:

| -    size => [8, 2],\n                                      |    |       |
| +    size => [undef, "ARRAY(0x5ddd837dfa08)"],\n            |    |       |

I suspect it was due to bucardo/dbdpg#162 I fed the information to claude code and it suggested the following:

Old DBD::Pg returns COLUMN_SIZE="2,8" and DECIMAL_DIGITS=undef. Since DECIMAL_DIGITS is undef, Schema Loader passes the string "2,8" to the Pg layer, which splits it into [8, 2].

New DBD::Pg (PR #162) returns COLUMN_SIZE=8 and DECIMAL_DIGITS=2 as separate integers. Since both are defined, the base Schema Loader layer pre-builds size=[8, 2] as an arrayref before the Pg layer sees it. The Pg layer then tries to regex-substitute that arrayref, which stringifies it to "ARRAY(0x...)", and the split produces [undef, "ARRAY(0x...)"]

It also suggested the following change to DBIx::Class::Schema::Loader::DBI::Pg::_columns_info_for:

elsif ( $data_type =~ /^(?:numeric|decimal)\z/i
  && ( my $size = $info->{size} ) )
{
    if (ref $size eq 'ARRAY') {
        # New DBD::Pg (PR #162+): base layer already built [precision, scale]
        # from separate COLUMN_SIZE and DECIMAL_DIGITS fields — use as-is
    }
    else {
        # Old DBD::Pg: COLUMN_SIZE was "scale,precision" combined string
        $size =~ s/\s*//g;
        my ( $scale, $precision ) = split /,/, $size;
        $info->{size} = [ $precision, $scale ];
    }
}

To be clear I haven't looked at these suggestions (particularly the suggested fix) in depth, but the root cause does seem to align.

[esabol]

Have you tested with DBD::Pg 3.20.0 released earlier today?

I would guess the situation is probably the same there, but just wondering. There were more related changes in that version.

[ugexe]

It'll be a couple of days before that release ages past our cooldown period for updates until it'll be retested on our end. I agree that the changes in 3.20.0 don't look like they would resolve this issue.

[turnstep]

No, 3.20.0 will not change the behavior. Apologies for the abrupt change in 3.19.0, but it was already broken, so we fixed the problem as well as put things where they should belong according to the DBI docs. Check this out:

$ perl -MDBI -e 'use lib "blib/lib","blib/arch"; $d=DBI->connect("dbi:Pg:");$d->do("create temp table t(x numeric(6,2))");$s=$d->column_info("","","t","x");printf "Version %s gives %s\n", $DBD::Pg::VERSION, $s->fetchall_arrayref({})->[0]{COLUMN_SIZE}'
Version 3.18.0 gives 2,6

$ perl -MDBI -e 'use lib "blib/lib","blib/arch"; $d=DBI->connect("dbi:Pg:");$d->do("create temp table t(x numeric(6,2))");$s=$d->column_info("","","t","x");printf "Version %s gives %s\n", $DBD::Pg::VERSION, $s->fetchall_arrayref({})->[0]{COLUMN_SIZE}'
Version 3.19.0 gives 6

That first one should be "6,2", not "2,6"

[robrwo]

I have the same issue