Next Previous Contents

11. Perl Database Interface (DBI) Driver for PostgreSQL

11.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, 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.

11.2 Perl Database Interface DBI

WHAT IS 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. The information for this DBI section is obtained from 'DBI FAQ' doc whose author is Alligator Descartes and reproduced here with his permission.

DBI driver for PostgreSQL DBD-Pg-0.63

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

REQUIREMENTS:

Technical support for DBI

Please send comments and bug-reports to

Please include the output of perl -v, and perl -V, the version of PostgreSQL, the version of DBD-Pg, and the version of DBI in your bug-report.

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.

DBperl is the old name for the interface specification. It's usually now used to denote perl4 modules on database interfacing, such as, oraperl, isqlperl, ingperl and so on. These interfaces didn't have a standard API and are generally not supported.

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
                                    <mpeppler@datamig.com>
                                    http://www.mbay.net/~mpeppler
    Oraperl     Oracle 6 & 7        Kevin Stock     DBD::Oracle
                                    <dbi-users@fugue.com>
    Ingperl     Ingres              Tim Bunce &     DBD::Ingres
                                    Ted Lemon
                                    <dbi-users@fugue.com>
    Interperl   Interbase           Buzz Moschetti  DBD::Interbase
                                    <buzz@bear.com>
    Uniperl     Unify 5.0           Rick Wargo      None
                                    <rickers@coe.drexel.edu>
    Pgperl      Postgres            Igor Metz       DBD::Pg
                                    <metz@iam.unibe.ch>
    Btreeperl   NDBM                John Co~over    SDBM?
                                    <john@johncon.com>
    Ctreeperl   C-Tree              John Conover    None
                                    <john@johncon.com>
    Cisamperl   Informix C-ISAM     Mathias Koerber None
                                    <mathias@unicorn.swi.com.sg>
    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.

Here's a table of emulation layer information:

    Module                  Emulation Layer     Status
    ------          ---------------     ------
    DBD::Oracle     Oraperl             Complete
    DBD::Informix   Isqlperl            Under development
    DBD::Sybase     Sybperl             Working? ( Needs verification )
    DBD::mSQL       Msqlperl            Experimentally released with
                                        DBD::mSQL-0.61
The Msqlperl emulation is a special case. Msqlperl is a perl5 driver for mSQL databases, but does not conform to the DBI Specification. It's use is being deprecated in favour of DBD::mSQL. Msqlperl may be downloaded from CPAN via:

DBI specifications

There are a few information sources on DBI.

There are two specifications available at this link, the new DBI Draft Specification which is a rapidly changing document as the development team drive towards a stable interface, and the old historical DBperl Specification out of which the current DBI interface evolved.

The later document should be regarded as being of historical interest only and should not serve as a programming manual, or authoratative in any sense. However, it is still a very useful reference source.

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 DBI Specification The POD for the DBI Specification can be read with the command

perldoc DBI

Oraperl 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

This will produce an updated copy of the original oraperl man page written by Kevin Stock for perl4. The oraperl API is fully listed and described there.

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

perldoc DBD::mSQL

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

perldoc DBI::FAQ

This may be more convenient to people not permanently, or conveniently, connected to the Internet.

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.

Rambles, Tidbits and Observations : There are a series of occasional rambles from various people on the DBI mailing lists.

``DBI -- The perl5 Database Interface'' This is an article written by Alligator Descartes and Tim Bunce on the structure of DBI. It was published in issue 5 of ``The Perl Journal''. It's extremely good. Go buy the magazine. In fact, buy all of them. ``The Perl Journal''s WWW site is:

``DBperl'' This article, published in the November 1996 edition of ``Dr. Dobbs Journal'' concerned DBperl.

``The Perl5 Database Interface'' This item is a book to be written by Alligator Descartes and published by O'Reilly and Associates.

Mailing Lists There are three mailing lists for DBI run by Ted Lemon. These can all be subscribed to and unsubscribed from via the World Wide Web at

The lists that users may participate in are:

dbi-announce This mailing list is for announcements only. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner:

dbi-dev This mailing list is intended for the use of developers discussing ideas and concepts for the DBI interface, API and driver mechanics. Only any use for developers, or interested parties. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner:

dbi-users This mailing list is a general discussion list used for bug reporting, problem discussion and general enquiries. If you cannot successfully use the form on the above WWW page, please subscribe to the list in the following manner:

Mailing List Archives

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. If you send us nothing, expect nothing back.

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.

What's DBM? And why use DBI instead ?

UNIX was originally blessed with simple file-based ``databases'', namely the dbm system. dbm lets you store data in files, and retrieve that data quickly. However, it also has serious drawbacks.

File Locking

The dbm systems did not allow particularly robust file locking capabilities, nor any capability for correcting problems arising through simultaneous writes [ to the database ].

Arbitrary Data Structures

The dbm systems only allows a single fixed data structure: key-value pairs. That value could be a complex object, such as a [ C ] struct, but the key had to be unique. This was a large limitation on the usefulness of dbm systems.

However, dbm systems still provide a useful function for users with simple datasets and limited resources, since they are fast, robust and extremely well-tested. Perl modules to access dbm systems have now been integrated into the core Perl distribution via the AnyDBM_File module.

To sum up, DBM is a perfectly satisfactory solution for essentially read-only databases, or small and simple datasets. However, for more powerful and scaleable datasets, not to mention robust transactional locking, users are recommended to use DBI.

Is < insert feature here > supported in DBI?

Given that we're making the assumption that the feature you have requested is a non-standard database-specific feature, then the answer will be no.

DBI reflects a generic API that will work for most databases, and has no database-specific functionality.

However, driver authors may, if they so desire, include hooks to database-specific functionality through the func method defined in the DBI API. Script developers should note that use of functionality provided via the func methods is unlikely to be portable across databases.

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!

Can I do multi-threading with DBI?

As of the current date, no. Perl does not support multi-threading. However, multi-threading is expected to become part of the perl core distribution as of version 5.005, which implies that DBI may support multi-threading fairly soon afterwards. 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);
    $sth->execute;

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

The Perl5 Database Interface is FREE software. IT COMES WITHOUT WARRANTY OF ANY KIND. However, some organizations are providing either technical support or training programs on DBI.

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 :


Next Previous Contents