Previous Next Contents

12. Perl Database Interface (DBI) Driver for PostgreSQL

12.1 Perl 5 interface for PostgreSQL

It is included in the distribution of PostgreSQL. Check in src/pgsql_perl5 directory.

12.2 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.

12.3 Announcement DBD-Pg-0.63 DBI driver for PostgreSQL

On its way to CPAN is DBD-Pg-0.63.tar.gz. Since the last public release the following changes have been made:

- - adapted to PostgreSQL-6.2: o $ sth->rows as well as $ sth->execute and $ sth->do return the number of affected rows even for non-Select statements. o support for password authorization added, please check the man-page for pg_passwd.

- - the data_source parameter of the connect method accepts two additional parameters which are treated as host and port: DBI->connect("dbi:Pg:dbname:host:port", "uid", "pwd")

- - support for AutoCommit, please read the module documentation for impacts on your scripts !

- - more perl-ish handling of data type bool, please read the module documentation for impacts on your scripts !

for further information see:

12.4 Release Notes and ReadMe file

# $Id: README,v 1.10 1997/10/05 18:25:55 mergl Exp $
# Portions Copyright (c) 1994,1995,1996,1997 Tim Bunce
# Portions Copyright (c) 1997                Edmund Mergl

*                                                        *
*            This release makes changes which are        *
*                      INCOMPATIBLE                      *
*                      ------------                      *
*                  to previous releases.                 *
*                                                        *
*        Please check the module documentation           *
*             for the attribute AutoCommit               *
*               and for the data type bool.              *
*                                                        *



This is version 0.63 of DBD-Pg. DBD-Pg is a PostgreSQL interface for Perl 5 using DBI.

For further information about DBI look at:



You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.



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.



- build, test and install Perl 5 (at least 5.002) - build, test and install the DBI module (at least 0.89) - build, test and install PostgreSQL (at least 6.2)



This release of DBD-Pg has been developed using Linux 2.0 with dynamic loading for the perl extensions. Let me know, if there are any problems with other platforms.



The Makefile checks the environment variable POSTGRES_HOME as well some standard locations, to find the root directory of your Postgres installation.

1. perl Makefile.PL 2. make 3. make test 4. make install

( 1. to 3. as normal user, not as root ! )



Run 'make test'. Note, that the user running this script must have been created with the access rights to create databases *AND* users ! Do not run this script as root !

If testing fails with the message 'login failed', please check if access to the database template1 as well as pgperltest is not protected in pg_hba.conf.

If you are using the shared library check if your dynamic loader finds With Linux the command /sbin/ldconfig -v should tell you, where it finds If ldconfig does not find, either add an appropriate entry to /etc/ and re-run ldconfig or add the path to the environment variable LD_LIBRARY_PATH. A typical error message resulting from not finding is: install_driver(Pg) failed: Can't load './blib/arch/auto/DBD/Pg/' for module DBD::Pg: File not found at

Some linux distributions have an incomplete perl installation. If you have compile errors like "XS_VERSION_BOOTCHECK undeclared", make a 'find .../lib/perl5 -name XSUB.h -print' If this file is not present, you need to recompile and reinstall perl.

SGI users: if you get segmentation faults make sure, you use the malloc which comes with perl when compiling perl (the default is not to). "David R. Noble"

--------------------------------------------------------------------------- October 05, 1997


12.5 FAQ for DBI

Below is the Frequently Asked question FAQ for DBI. The main web page is at

                   DBI Frequently Asked Questions v.0.35
                       Last updated: June 20th, 1997

* Basic Information & Information Sources

   * 1.1 What is DBI, DBperl, Oraperl and *perl?
   * 1.2. Where can I get it from?
   * 1.3. Where can I get more information?

* Compilation Problems

   * 2.1. Compilation problems or "It fails the test!"

* Platform and Driver Issues

   * 3.1 What's the difference between ODBC and DBI?
   * 3.2 Is DBI supported under Windows 95 / NT platforms?
   * 3.3 Can I access Microsoft Access or SQL-Server databases with DBI?
   * 3.4 Is the a DBD for >?
   * 3.5 What's DBM? And why should I use DBI instead?
   * 3.6 When will mSQL-2 be supported?
   * 3.7 What database do you recommend me using?
   * 3.8 Is > supported in DBI?

* Programming Questions

   * 4.1 Is DBI any use for CGI programming?
   * 4.2 How do I get faster connection times with DBD::Oracle and CGI?
   * 4.3 How do I get persistent connections with DBI and CGI?
   * 4.4 ``When I run a perl script from the command line, it works, but,
     when I run it under the C, it fails!'' Why?
   * 5.1 Can I do multi-threading with DBI?
   * 5.2 How do I handle BLOB data with DBI?
   * 5.3 How can I invoke stored procedures with DBI?
   * 5.4 How can I get return values from stored procedures with DBI?
   * 5.5 How can I create or drop a database with DBI?
   * 5.6 How can I C or C a statement with DBI?
   * 5.7 How are C values handled by DBI?
   * 5.8 What are these C methods all about?

* Support and Training

   * Commercial Support
   * Training

* Other References



DBI::FAQ -- The Frequently Asked Questions for the Perl5 Database Interface



    perldoc DBI::FAQ



This document is currently at version 0.35, as of June 20th, 1997.



This document serves to answer the most frequently asked questions on both
the DBI Mailing Lists and personally to members of the DBI development team.


Basic Information & Information Sources


1.1 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

Here's a diagram that demonstrates the principle:

                            [ DBI Architecture ]

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. Please note, the author's listed here generally do not
maintain the DBI module for the same database. These email addresses are
unverified and should only be used for queries concerning the perl4 modules
listed below. DBI driver queries should be directed to the dbi-users mailing

    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.

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

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:


1.2. Where can I get it from?

DBI is primarily distributed from:

The Comprehensive Perl Archive Network resources should be used for
retrieving up-to-date versions of the drivers, since local mirror sites
usually lag. CPAN may be accessed via Tom Christiansen's splendid CPAN
multiplexer program located at:

For more specific version information and exact URLs of drivers, please see
the DBI drivers list and the DBI module pages which can be found on:


1.3. Where can I get more information?

There are a few information sources on DBI.

DBI Specification

     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 latter 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:

              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

          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.

          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
          This document, the Frequently Asked Questions is also available as
          POD documentation! You can read this on your own system 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 who, in an attempt to clear up a simple point, end up
     drafting fairly comprehensive documents. These are quite often varying
     in quality, but do provide some insights into the workings of the

``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:

     This article, published in the November 1996 edition of ``Dr. Dobbs
     Journal'' concerned DBperl. The author of this edition apparently did
     not bother to contact any of the DBI development team members for
     verification of the information contained within his article. Several
     reviews of the article on the dbi-users mailing list were disparaging,
     to say the least. The fact the article was written about DBperl instead
     of DBI hints at the staleness of the information.

     However, we include the reference for completeness' sake.

``The Perl5 Database Interface''
     This item is a book to be written by Alligator Descartes ( for it is me
     ) and published by O'Reilly and Associates this coming Winter.

     Here is the putative table of contents for the book.

          * Introduction
               + Databases
               + CGI / WWW
               + perl
          * Basic Database Concepts
               + Types of Database
                    o Flat File
                    o AnyDBM
                    o RDBMS
               + Using Which Database For What...
          * SQL
               + Why SQL?
               + Structuring Information In Databases
               + Retrieving Data From Databases
               + Manipulating Data and Data Structures
          * DBI Architecture
          * Programming with DBI
               + DBI Initialization
               + Handles
                    o Driver Handles
                    o Database Handles
                    o Statement Handles
               + Connection and Disconnection
               + Handling Errors
               + Issuing Simple Queries
               + Executing Atomic Statements
               + Statement MetaData
               + More perl-ish Statements
               + Binding
               + Transaction Handling
               + Utility Methods
               + Handle Attributes and Dynamic Variables
          * DBI and ODBC
          * The Database Drivers
               + DBD::Oracle and oraperl
               + DBD::Informix and isqlperl
               + DBD::mSQL and Msqlperl
          * Case Studies
               + DBI and the WWW
               + Data Migration and Warehousing
               + Administration Software
          * Appendix: API Reference / Specification
          * Appendix: Resources

README files
     The README files included with each driver occasionally contains some
     useful information ( no, really! ) that may be pertinent to the user.
     Please read them. It makes our worthless existences more bearable.
     These can all be read from the main DBI WWW page at:

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
     URL of:

     The lists that users may participate in are:

          This mailing list is for announcements only. Very low traffic. The
          announcements are usually posted on the main DBI WWW page.

          If you cannot successfully use the form on the above WWW page,
          please subscribe to the list in the following manner:

              Email: '' with a message body of

          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. Low

          If you cannot successfully use the form on the above WWW page,
          please subscribe to the list in the following manner:

              Email: '' with a message body of

          This mailing list is a general discussion list used for bug
          reporting, problem discussion and general enquiries. Medium

          If you cannot successfully use the form on the above WWW page,
          please subscribe to the list in the following manner:

              Email: '' with a message body of

Mailing List Archives
     US Mailing List Archives


          Searchable hypermail archives of the three mailing lists, and some
          of the much older traffic have been set up for users to browse.

     European Mailing List Archives


          As per the US archive above.


Compilation Problems


2.1. Compilation problems or "It fails the test!"

First off, consult the online information about the module, beit DBI itself,
or a DBD, and see if it's a known compilation problem on your architecture.
These documents can be found at:

If it's a known problem, you'll probably have to wait till it gets fixed. If
you're really needing it fixed, try the following:

Attempt to fix it yourself
     This technique is generally not recommended to the faint-hearted. If
     you do think you have managed to fix it, then, send a patch file (
     context diff ) to the author with an explanation of:

        o What the problem was, and test cases, if possible.

        o What you needed to do to fix it. Please make sure you mention

        o Platform information, database version, perl version, module
          version and DBI version.

Email the author Do NOT whinge!
     Please email the address listed in the WWW pages for whichever driver
     you are having problems with. Do not directly email the author at a
     known address unless it corresponds with the one listed.

     We tend to have real jobs to do, and we do read the mailing lists for
     problems. Besides, we may not have access to <insert your favourite
     brain-damaged platform here> and couldn't be of any assistance anyway!
     Apologies for sounding harsh, but that's the way of it!

     However, you might catch one of these creative genii at 3am when we're
     doing this sort of stuff anyway, and get a patch within 5 minutes. The
     atmosphere in the DBI circle is that we do appreciate the users'
     problems, since we work in similar environments.

     If you are planning to email the author, please furnish as much
     information as possible, ie:

        o ALL the information off the README file in the problematic module.
          And we mean ALL of it. We don't put lines like that in
          documentation for the good of our health, or to meet obscure
          README file standards of length.

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


        o Module versions, perl version, test cases, operating system
          versions and any other pertinent information.

     Remember, the more information you send us, the quicker we can track
     problems down. If you send us nothing, expect nothing back.

Email the dbi-users Mailing List
     It's usually a fairly intelligent idea to cc the mailing list anyway
     with problems. The authors all read the lists, so you lose nothing by
     mailing there.


Platform and Driver Issues


3.1 What's the difference between ODBC and DBI?

Good question! To be filled in more detail!


3.2 Is DBI supported under Windows 95 / NT platforms?

Finally, yes! Jeff Urlwin has been working diligently on building DBI and
DBD::Oracle under these platforms, and, with the advent of a stabler perl
and a port of MakeMaker, the project has come on by great leaps and bounds.

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. For the
DBD::Oracle patches required, please read the Win32 porting page at:


3.3 Can I access Microsoft Access or SQL-Server databases with DBI?

    Contributed by Tim Bunce and Jeff Urlwin

Supplied with DBI-0.79 ( and later ) is an experimental DBI 'emulation
layer' for the Win32::ODBC module. It's called DBI::W32ODBC and is, at the
moment, very minimal. You will need the Win32::ODBC module available from:

Given its status, problem reports without fixes are likely to be ignored.
You will also need the Win32 DBI patch kit as supplied by Jeff Urlwin, which
you can locate by reading the previous question's answer.

Jeff Urlwin is currently working hard on the ODBC layer.

To get back to the question, theoretically, yes, you can access Microsoft
Access and SQL-Server databases from DBI via ODBC!


3.4 Is the a DBD for <insert favourite database here>?

Is is listed on the DBI drivers page?

If not, no. A complete absence of a given database driver from that page
means that no-one has announced any intention to work on it.

A corollary of the above statement implies that if you see an announcement
for a driver not on the above page, there's a good chance it's not actually
a DBI driver, and may not conform to the specifications. Therefore,
questions concerning problems with that code should not really be addressed
to the DBI Mailing Lists.


3.5 What's DBM? And why should I use DBI instead?

Extracted from ``DBI - The Database Interface for Perl 5'':

    ``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.


3.6 When will mSQL-2 be supported?

As of DBD::mSQL-0.61, there has been support for mSQL-2. However, there is
no real support for any of the new methods added to the core mSQL library
regarding index support yet. These are forthcoming and will be accessible
via func methods private to DBD::mSQL. You can read more about these private
methods in the DBD::mSQL POD that can be found by typing:

    perldoc DBD::mSQL

provided you have DBD::mSQL correctly installed.


3.7 What database do you recommend me using?

This is a particularly thorny area in which an objective answer is difficult
to come by, since each dataset, proposed usage and system configuration
differs from person to person.

From the current author's point of view, if the dataset is relatively small,
being tables of less than 1 million rows, and less than 1000 tables in a
given database, then mSQL is a perfectly acceptable solution to your
problem. This database is extremely cheap, is wonderfully robust and has
excellent support. More information is available on the Hughes Technology
WWW site at:

If the dataset is larger than 1 million row tables or 1000 tables, or if you
have either more money, or larger machines, I would recommend Oracle7 RDBMS.
Oracle's WWW site is an excellent source of more information.

Informix is another high-end RDBMS that is worth considering. There are
several differences between Oracle and Informix which are too complex for
this document to detail. Information on Informix can be found on their WWW
site at:

In the case of WWW fronted applications, mSQL may be a better option due to
slow connection times between a CGI script and the Oracle RDBMS and also the
amount of resource each Oracle connection will consume. mSQL is lighter
resource-wise and faster.

These views are not necessarily representative of anyone else's opinions,
and do not reflect any corporate sponsorship or views. They are provided


3.8 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.


Programming Questions


4.1 Is DBI any use for CGI programming?

In a word, yes! DBI is hugely useful for CGI programming! In fact, I would
tentatively say that 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


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

    Contributed by John D. Groenveld

The Apache httpd maintains a pool of httpd children to service client

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:

The mod_perl module can be downloaded from CPAN via:


4.3 How do I get persistent connections with DBI and CGI?

    Contributed by John D. Groenveld

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:


4.4 ``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

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

The ``Idiot's Guide To Solving Perl / CGI Problems'' can be located at:

as can the ``Perl CGI Programming FAQ''. Read BOTH these documents


5.1 Can I do multi-threading with DBI?

As of the current date of this FAQ ( see top of page ), 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:


5.2 How do I handle BLOB data with DBI?

To be written.


5.3 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" );


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

    Contributed by Jeff Urlwin

    $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);

Remember to perform error checking, though!


5.5 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

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.


5.6 How can I commit or rollback a statement with DBI?

To be written.


5.7 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.


5.8 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.


Support and Training

The Perl5 Database Interface is FREE software. IT COMES WITHOUT WARRANTY OF

However, some organizations are providing either technical support or
training programs on DBI. The present author has no knowledge as to the
quality of these services. The links are included for reference purposes


Commercial Support

The 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:

     for more details.



No training programs are known at this time.


Other References

In this section, we present some miscellaneous WWW links that may be of some
interest to DBI users. These are not verified and may result in unknown
sites or missing documents.



Alligator Descartes <>

Reproduced here by permission from Alligator Descartes Hermetica

Previous Next Contents