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.
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.
Get DBD-Pg-0.89.tar.gz from below
REQUIREMENTS:
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.
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 Conover 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
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
There are a few information sources on DBI.
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
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.
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.
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.
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.
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.
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:
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:
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!
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:
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" );
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;
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.
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 )" );
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' );
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 :