For the sake of completeness: SQL-standard compliant databases have table information_schema_catalog_name, which always contains one row and one column containing the name of the current database (the current 'catalog', in SQL terminology).

(The SQL standard says "The value of CATALOG_NAME is the name of the catalog in which this Information Schema resides.")

PostgreSQL example:

testdb=# select CATALOG_NAME from INFORMATION_SCHEMA.INFORMATION_SCHEM
+A_CATALOG_NAME;
 catalog_name 
--------------
 testdb
(1 row)
[download]

I'd normally prefer DBI, but the SQL can be handy.

(And FWIW: postgres also supports the more succinct and standard-compliant CURRENT_CATALOG:)

 testdb=# select current_catalog;
 current_database 
------------------
 testdb
(1 row)
[download]

And then there is DBI's get_info stuff:

use DBI::Const::GetInfoType;

say "SQL_DBMS_NAME     [",$dbh->get_info($GetInfoType{SQL_DBMS_NAME   
+ }),"]";
say "SQL_DBMS_VER      [",$dbh->get_info($GetInfoType{SQL_DBMS_VER    
+ }),"]";
say "SQL_DATABASE_NAME [",$dbh->get_info($GetInfoType{SQL_DATABASE_NAM
+E}),"]";
say "SQL_SERVER_NAME   [",$dbh->get_info($GetInfoType{SQL_SERVER_NAME 
+ }),"]";

-- output
SQL_DBMS_NAME     [PostgreSQL]
SQL_DBMS_VER      [09.02.0000]
SQL_DATABASE_NAME [testdb]
SQL_SERVER_NAME   [testdb]
[download]

update: Jenda: Re SQL-standard versions: PostgreSQL supports generally quite recent versions: SQL:2011 and SQL:2008. And even SQL92 already prescribed INFORMATION_SCHEMA_CATALOG_NAME.

Some systems are more SQL-compliant than others. PostgreSQL tries quite hard to implement as much as possible.

Doesn't work in Microsoft SQL Server 2008 R2 (RTM) - 10.50.1617.0 (X64) (Build 7601: Service Pack 1). I wonder what version of the standard ...

select DISTINCT CATALOG_NAME from INFORMATION_SCHEMA.SCHEMATA does.

Jenda
Enoch was right!
Enjoy the last years of Rome.

Incidently, if you have multiple databases, it's often useful to be able to tell which one you're currently connected to. You -could- theoretically store the current database name in a variable, but sometimes it's just easier to access it via the handle. I use the above format myself occasionally.

It turns out that $dbh->{'Name'} is not a reliable source for the database name; DBI docs say:

Holds the "name" of the database. Usually (and recommended to be) the same as the "dbi:DriverName:..." string used to connect to the database, but with the leading "dbi:DriverName:" removed.

DBD::Pg complies wth that description: it simply returns the connectionstring minus the prefix.

So it would seem that if $dbh->{'Name'} returns the database name it's by accident.

In other words, it holds the part after the driver indication in the DSN part. When e.g. connecting to CSV like

my $dbh = DBI->connect ("dbi:CSV:f_ext=.csv/r;f_encoding=utf-8", undef
+, undef, { RaiseError => 1 });
[download]

The return values for $dbh->{Name} will be f_ext=.csv/r;f_encoding=utf-8, which might not be very useful information.

The fact the DBD::Pg in your case returns the correct database name, might be because you initiated the connection using something like

my $dbh = DBI->connect ("dbi:Pg:dbname=test", ...);
[download]

but when you connect using just "dbi:Pg:" in combination with the environment variable $PGDATABASE, you might not get anything useful at all

$ env PGDATABASE=merijn perl -MDBI -wE'say DBI->connect("dbi:Pg:")->{N
+ame}||"not known"'
not known
$
[download]


Enjoy, Have FUN! H.Merijn

thanks for the solution TJPride

Why would you need to determine this info from a handle?

RFM :) perldoc DBI, read about attributes like Name