Closed mrmuskrat closed 3 years ago
It should also work with a service connection file too.
Which version of DBD::Pg and libpq are you using? That error message is from libpq, but it has supported application_name
since version 9.0.
1> my $dbh = DBI->connect("dbi:Pg:application_name=reply")
$res[1] = bless( {}, 'DBI::db' )
2> $dbh->selectrow_array('show application_name')
$res[2] = 'reply'
3> DBD::Pg->VERSION
$res[3] = '3.13.0'
6> $dbh->{pg_lib_version}
$res[4] = 120003
I feel like an idiot now. We're moving our applications around and I should have checked the original containers. We somehow have an older version of libpq where I was trying to test and I didn't notice.
Sorry about that.
On 2/6/2021 11:37:32 AM, Dagfinn Ilmari Mannsåker notifications@github.com wrote:
Which version of DBD::Pg and libpq are you using? That error message is from libpq, but it has supported application_name since version 9.0.
1> my $dbh = DBI->connect("dbi:Pg:application_name=reply") $res[1] = bless( {}, 'DBI::db' )
2> $dbh->selectrow_array('show application_name') $res[2] = 'reply'
3> DBD::Pg->VERSION $res[3] = '3.13.0'
6> $dbh->{pg_lib_version} $res[4] = 120003
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.
When I try to pass application_name as a connection parameter as documented in the libpq-connect docs I get an error: invalid connection option "application_name"
I know... It's not documented to work in DBD::Pg but it should. Java and Python can set it and Perl should be able to as well!
If I can set $ENV{PGAPPNAME} soon enough in the process that usually works but it's not always feasible to do so.
In the meantime, I'm issuing a
SET application_name = 'foo'
after connection (via DBIx::Class::Storage::DBI's on_connect_do/connect_info, scroll up to see the real-life examples).