NAME

DBD::Pg - PostgreSQL database driver for the DBI module

SYNOPSIS

use DBI;

$dbh = DBI->connect("dbi:Pg:$dbname", $user, $passwd);

# See the DBI module documentation for full details

DESCRIPTION

DBD::Pg is a Perl module which works with the DBI module to provide access to PostgreSQL databases.

CONNECTING TO POSTGRESQL

To connect to a database you can say:

$dbh = DBI->connect('dbi:Pg:dbname:host:port', 'username', 'password');

The first parameter specifies the driver, the database and the optional host and port. The second and third parameter specify the username and password. This returns a database handle which can be used for subsequent database interactions. Please refer to the pg_passwd man-page for the different types of authorization.

SIMPLE STATEMENTS

Given a database connection, you can execute an arbitrary statement using:

$dbh->do($stmt);

The statement must not be a SELECT statement (except SELECT...INTO TABLE).

PREPARING AND EXECUTING STATEMENTS

You can prepare a statement for multiple uses, and you can do this for SELECT statements which return data as well as for statements which return no data. You create a statement handle using:

$sth = $dbh->prepare($stmt);

Once the statement is prepared, you can execute it:

$rv = $sth->execute;

$rv is the number of selected / affected rows. You can retrieve the values in the following way:

while ($ary_ref = $sth->fetch) {

}

Another possibility is to bind the fields of a select statement to perl variables. Whenever a row is fetched from the database the corresponding perl variables will be automatically updated:

$sth->bind_columns(undef, @list_of_refs_to_vars_to_bind);
while ($sth->fetch) {

}

When you have fetched as many rows as required, you close the statement handle using:

$sth->finish;

This frees the statement, but it does not free the related data structures. This is done when you destroy (undef) the statement handle:

undef $sth;

DISCONNECTING FROM A DATABASE

You can disconnect from the database:

$dbh->disconnect;

Note that this does not destroy the database handle. You need to do an explicit 'undef $dbh' to destroy the handle.

DYNAMIC ATTRIBUTES

The following attributes are supported:

$DBI::err	# error status

$DBI::errstr	# error message

$DBI::rows	# row count

STATEMENT HANDLE ATTRIBUTES

For statement handles of a select statement you can discover what the returned column names, types, sizes are:

@name = @{$sth->{'NAME'}};	# Column names
@type = @{$sth->{'TYPE'}};	# Data types
@size = @{$sth->{'SIZE'}};	# Numeric size

There is also support for two PostgreSQL-specific attributes:

$oid_status = $sth->{'pg_oid_status'};	# oid of last insert
$cmd_status = $sth->{'pg_cmd_status'};	# type of last command

TRANSACTIONS

The transaction behavior is now controlled with the attribute AutoCommit. For a complete definition of AutoCommit please refer to the DBI documentation.

According to the DBI specification the default for AutoCommit is TRUE. In this mode, any change to the database becomes valid immediately. Any 'begin', 'commit' or 'rollback' statement will be rejected.

If AutoCommit is switched-off, immediately a transaction will be started by issuing a 'begin' statement. Any 'commit' or 'rollback' will start a new transaction. A disconnect will issue a 'rollback' statement.

In case your scripts do not use transactions, no changes are necessary. If your scripts make use of transactions, you have to adapt them to the AutoCommit feature. In most cases it is be sufficient, to remove the 'begin' statements and to switch-off the AutoCommit mode.

DATA TYPE bool

The current implementation of PostgreSQL returns 't' for true and 'f' for false. From the perl point of view a rather unfortunate choice. Starting with this release, the DBD-Pg module translates the result for the data type bool in a more perl-ish like manner: 'f' -> '0' and 't' -> '1'. This way the application does not have to check the database-specific return values for the data type bool, because perl treats '0' as false and '1' as true. If you make use of the data type bool you have to adapt your scripts !

There is still one drawback: in INSERT or UPDATE statements you have to stay with 't' for true instead of '1', because PostgreSQL accepts almost anything as input but treats it as false. This behavior might change in the next release of PostgreSQL.

BLOBS

Support for blob_read is provided. For further information and examples please read the files in the blobs subdirectory. In addition you can use the two registered built-in functions lo_import() and lo_export(). See the large_objects for further information and examples.

KNOWN RESTRICTIONS

  • PostgreSQL does not has the concept of preparing a statement. Here the prepare method just stores the statement.

  • Although PostgreSQL has a cursor concept, it has not been used in the current implementation. Cursors in PostgreSQL can only be used inside a transaction block. Because transactions in PostgreSQL can not be nested, this would have implied the restriction, not to use any nested SELECT statements. Hence the execute method fetches all data at once into data structures located in the frontend application. This has to be considered when selecting large amounts of data !

  • $DBI::state is not supported.

  • Some statement handle attributes are not supported.

SEE ALSO

DBI

AUTHORS

  • DBI and DBD-Oracle by Tim Bunce (Tim.Bunce@ig.co.uk)

  • DBD-Pg by Edmund Mergl (E.Mergl@bawue.de)

    Major parts of this package have been copied from DBI and DBD-Oracle.

COPYRIGHT

The DBD::Pg module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

ACKNOWLEDGMENTS

See also "ACKNOWLEDGMENTS" in DBI.

4 POD Errors

The following errors were encountered while parsing the POD:

Around line 298:

'=item' outside of any '=over'

Around line 321:

You forgot a '=back' before '=head1'

Around line 328:

'=item' outside of any '=over'

Around line 337:

You forgot a '=back' before '=head1'