Next Previous Contents

10. Perl Database Interface (DBI) Driver for PostgreSQL

10.1 Perl 5 interface for PostgreSQL

PERL is an acronym for 'Practical Extraction and Report Language'. Perl is available on each and every operating system and hardware platform in the world. You can use Perl on Windows95/NT, Apple Macintosh iMac, all flavors of Unix (Solaris, HPUX, AIX, Linux, Irix, SCO etc..), mainframe MVS, desktop OS/2, OS/400, Amdahl UTS and many others. Perl runs EVEN on many unpopular or generally-unknown operating systems and hardware!! So do not be surprised if you see perl running on a very rarely used operating system. You can imagine the vast extent of the user base and developer base of Perl.

Perl interface for PostgreSQL is included in the distribution of PostgreSQL. Check in src/pgsql_perl5 directory.

10.2 Perl Database Interface DBI


The Perl Database Interface (DBI) is a database access Application Programming Interface (API) for the Perl Language. The Perl DBI API specification defines a set of functions, variables and conventions that provide a consistent database interface independent of the actual database being used.

DBI driver for PostgreSQL DBD-Pg-0.89

Get DBD-Pg-0.89.tar.gz from below

Technical support for DBI

What is DBI, DBperl, Oraperl and *perl?

To quote Tim Bunce, the architect and author of DBI:

``DBI is a database access Application Programming Interface (API) for the Perl Language. The DBI API Specification defines a set of functions, variables and conventions that provide a consistent database interface independent of the actual database being used.''

In simple language, the DBI interface allows users to access multiple database types transparently. So, if you connecting to an Oracle, Informix, mSQL, Sybase or whatever database, you don't need to know the underlying mechanics of the 3GL layer. The API defined by DBI will work on all these database types.

A similar benefit is gained by the ability to connect to two different databases of different vendor within the one perl script, ie, I want to read data from an Oracle database and insert it back into an Informix database all within one program. The DBI layer allows you to do this simply and powerfully.

Here's a list of DBperl modules, their corresponding DBI counterparts and support information. DBI driver queries should be directed to the dbi-users mailing list.

    Module Name Database Required   Author          DBI
    ----------- -----------------   ------          ---
    Sybperl     Sybase              Michael Peppler DBD::Sybase
    Oraperl     Oracle 6 & 7        Kevin Stock     DBD::Oracle
    Ingperl     Ingres              Tim Bunce &     DBD::Ingres
                                    Ted Lemon
    Interperl   Interbase           Buzz Moschetti  DBD::Interbase
    Uniperl     Unify 5.0           Rick Wargo      None
    Pgperl      Postgres            Igor Metz       DBD::Pg
    Btreeperl   NDBM                John Conover    SDBM?
    Ctreeperl   C-Tree              John Conover    None
    Cisamperl   Informix C-ISAM     Mathias Koerber None
    Duaperl     X.500 Directory     Eric Douglas    None
                User Agent
However, some DBI modules have DBperl emulation layers, so, DBD::Oracle comes with an Oraperl emulation layer, which allows you to run legacy oraperl scripts without modification. The emulation layer translates the oraperl API calls into DBI calls and executes them through the DBI switch.

DBI specifications

There are a few information sources on DBI.

POD documentation PODs are chunks of documentation usually embedded within perl programs that document the code ``in place'', providing a useful resource for programmers and users of modules. POD for DBI and drivers is beginning to become more commonplace, and documentation for these modules can be read with the following commands.

The POD for the DBI Specification can be read with the command 
        $ perldoc DBI

Users of the Oraperl emulation layer bundled with DBD::Oracle, may
read up on how to program with the Oraperl interface by typing:
        $ perldoc Oraperl

Users of the DBD::mSQL module may read about some of the private
functions and quirks of that driver by typing:
        $ perldoc DBD::mSQL

The Frequently Asked Questions is also available as
POD documentation. Read this by typing:
        $ perldoc DBI::FAQ

POD in general - Information on writing POD, and on the philosophy of POD in
general, can be read by typing:
        $ perldoc perlpod

Users with the Tk module installed may be interested to learn there is a Tk-based POD reader available called tkpod, which formats POD in a convenient and readable way.

See also -

The mailing lists that users may participate in are:

Compilation problems or "It fails the test"

If you have a core dump, try the Devel::CoreStack module for generating a stack trace from the core dump. Devel::CoreStack can be found on CPAN at:

Email the dbi-users Mailing List stack trace, module versions, perl version, test cases, operating system versions and any other pertinent information. The more information you send, the quicker developers can track problems down.

Is DBI supported under Windows 95 / NT platforms?

The DBI and DBD::Oracle Win32 ports are now a standard part of DBI, so, downloading DBI of version higher than 0.81 should work fine. You can access Microsoft Access and SQL-Server databases from DBI via ODBC. Supplied with DBI-0.79 (and later) is an experimental DBI 'emulation layer' for the Win32::ODBC module. It's called DBI::W32ODBC. You will need the Win32::ODBC module.

Is DBI any use for CGI programming?

In a word, yes! DBI is hugely useful for CGI programming! In fact, CGI programming is one of two top uses for DBI.

DBI confers the ability to CGI programmers to power WWW-fronted databases to their users, which provides users with vast quantities of ordered data to play with. DBI also provides the possibility that, if a site is receiving far too much traffic than their database server can cope with, they can upgrade the database server behind the scenes with no alterations to the CGI scripts.

How do I get faster connection times with DBD Oracle and CGI?

The Apache httpd maintains a pool of httpd children to service client requests. Using the Apache mod_perl module by Doug MacEachern, the perl interpreter is embedded with the httpd children. The CGI, DBI, and your other favorite modules can be loaded at the startup of each child. These modules will not be reloaded unless changed on disk. For more information on Apache, see the Apache Project's WWW site:

How do I get persistent connections with DBI and CGI?

Using Edmund Mergl's Apache::DBI module, database logins are stored in a hash with each of these httpd child. If your application is based on a single database user, this connection can be started with each child. Currently, database connections cannot be shared between httpd children. Apache::DBI can be downloaded from CPAN via:

``When I run a perl script from the command line, it works, but, when I run it under the httpd, it fails!'' Why?

Basically, a good chance this is occurring is due to the fact that the user that you ran it from the command line as has a correctly configured set of environment variables, in the case of DBD::Oracle, variables like $ORACLE_HOME, $ORACLE_SID or TWO_TASK. The httpd process usually runs under the user id of nobody, which implies there is no configured environment. Any scripts attempting to execute in this situation will correctly fail. To solve this problem, set the environment for your database in a BEGIN ( ) block at the top of your script. This will solve the problem. Similarly, you should check your httpd error logfile for any clues, as well as the ``Idiot's Guide To Solving Perl / CGI Problems'' and ``Perl CGI Programming FAQ'' for further information. It is unlikely the problem is DBI-related. Read BOTH these documents carefully!

Multi-threading with DBI?

For some OCI example code for Oracle that has multi-threaded SELECT statements, see:

How can I invoke stored procedures with DBI?

Assuming that you have created a stored procedure within the target database, eg, an Oracle database, you can use $dbh->do to immediately execute the procedure. For example,

$dbh->do( "BEGIN someProcedure END" );

How can I get return values from stored procedures with DBI?

Remember to perform error checking, though!

    $sth = $dbh->prepare( "BEGIN foo(:1, :2, :3); END;" );
    $sth->bind_param(1, $a);
    $sth->bind_param_inout(2, \$path, 2000);
    $sth->bind_param_inout(3, \$success, 2000);

How can I create or drop a database with DBI?

Database creation and deletion are concepts that are entirely too abstract to be adequately supported by DBI. For example, Oracle does not support the concept of dropping a database at all! Also, in Oracle, the database server essentially is the database, whereas in mSQL, the server process runs happily without any databases created in it. The problem is too disparate to attack. Some drivers, therefore, support database creation and deletion through the private func methods. You should check the documentation for the drivers you are using to see if they support this mechanism.

How are NULL values handled by DBI?

NULL values in DBI are specified to be treated as the value undef. NULLs can be inserted into databases as NULL, for example:

    $rv = $dbh->do( "INSERT INTO table VALUES( NULL )" );
but when queried back, the NULLs should be tested against undef. This is standard across all drivers.

What are these func methods all about?

The func method is defined within DBI as being an entry point for database-specific functionality, eg, the ability to create or drop databases. Invoking these driver-specific methods is simple, for example, to invoke a createDatabase method that has one argument, we would write:

    $rv = $dbh->func( 'argument', 'createDatabase' );
Software developers should note that the func methods are non-portable between databases.

Commercial Support and Training

PERL CLINIC : The Perl Clinic can arrange commercial support contracts for Perl, DBI, DBD::Oracle and Oraperl. Support is provided by the company with whom Tim Bunce, author of DBI, works. For more information on their services, please see :

10.3 Testing Perl interface

See the section - Testing Perl PostgreSQL interface

Next Previous Contents