in reply to Recommendations on module for Perl <-> PostgreSQL interaction

Your best shot should be DBD::pg for normal use. It is a module dependant on the DBI and it would allow you to apply some general knowledge to your specific problem. Meaning that, once you learn how to use Postgres from the DBI, you can also use whichever other database without much effort.

An alternative, useful in cases when you can't install the Postrgres client, is DBD:PgPP. From its docs:
DBD::PgPP is a Pure Perl client interface for the PostgreSQL database. This module implements network protocol between server and client of PostgreSQL, thus you don't need external PostgreSQL client library like libpq for this module to work. It means this module enables you to connect to PostgreSQL server from some operation systems which PostgreSQL is not ported.

Finally, there is DBD::ODBC, which will access your database through the ODBC interface. Be aware that, while this is a generalized approach that will smooth the differences between databases, it will aslo pre-process your queries, adding some overhead that in several cases can account to up to 20-30% of your performance.

Pg and PgSQL haven't been updated for years, and I would not start with them.

_ _ _ _ (_|| | |(_|>< _|

Replies are listed 'Best First'.
Re: Re: Recommendations on module for Perl <-> PostgreSQL interaction
by diotalevi (Canon) on Jun 25, 2003 at 14:46 UTC

    You wouldn't start with Pg but it can be a destination. DBD::Pg suffers by having to read the entire result set into memory before using it. Pg can perform both asynchronous queries and has support for cursors. If you're dealing with large data sets then DBD::Pg may just be entirely inappropriate. There's a Pg::Smart or something named like that that picks up where Pg left off and is more DBI-like except with all the good bits.