| CC: | Michelle Franz <michelle.franz [...] iovation.com>, Diego Narvaez <diego.narvaez [...] iovation.com> |
| Subject: | client_min_messages FATAL Borks errstr |
| Date: | Tue, 24 Nov 2015 10:26:10 -0800 |
| To: | DBD-Pg RT Queue <bug-dbd-pg [...] rt.cpan.org> |
| From: | "David E. Wheeler" <dwheeler [...] cpan.org> |
This code:
use DBI;
my $dbh = DBI->connect('dbi:Pg:', undef, undef, {
PrintError => 0,
RaiseError => 1,
AutoCommit => 1,
pg_server_prepare => 1,
});
END { $dbh->disconnect; }
$dbh->do('SET client_min_messages = FATAL');
eval {
$dbh->selectcol_arrayref('SELECT 1 FROM nonesuch');
};
say "Errstr: ", $dbh->errstr;
say "Error: $@";
Outputs:
Errstr: 7
Error: DBD::Pg::db selectcol_arrayref failed: at /Users/david/bin/try line 20.
Note that while $@ is set properly, errstr is not: it just emits “7”. This is not very helpful for code that expects it to have something.
While I’ll grant you that setting client_min_messages to FATAL is a really bad idea, we actually ran into this situation thanks to a mistake in our Puppet Postgres configuration. It’d be awesome if, instead of “7”, DBD::Pg noticed when there was no error string at all and reported that. Maybe something like:
Errstr: No error returned from Postgres; Perhaps client_min_messages is set too high?
That would at least allow us to have an idea what’s going on.
Thanks,
David