There are three different modules and the one you should use is neither of the ones mentioned so far. Pg is a non-DBI interface. DBD::PgPP is a useful hack if you want to use DBI and can't install the real module. DBD::Pg is the best way to access PostgreSQL from DBI. It is updated and maintained by a team from PostgreSQL. It may be a bit harder to install than DBD::PgPP, but is much better. | [reply] |
Pg looks to be old (last update Apr 2000), so just off that DBD::PgPP is probably better. Do you have a specific reason for needing to use DBD::PgPP instead of DBD::Pg? I don't know for sure, but i would suspect that the latter is better (more robust & better supported), unless of course you need PgPP's ability to run where a PostgreSQL client library is not available. | [reply] |
unless of course you need PgPP's ability to run where a PostgreSQL client library is not available.
That's exactly the reason :)
Thanks,
| [reply] |
This logic, "looks to be old," therefore the other is "better," is flawed. There are plenty of modules on CPAN which do exactly what they are meant to do and have not required patches and thus remain "old." Another word for this is "stable." In this case, your invalid logic have lead you to the correct conclusion. So you're right in spite of yourself. Pg is a direct wrapper over the PostgreSQL C API. Recently, the PostgreSQL core team took over maintenance of DBD::Pg as well as Pg. They deprecated Pg in favor of DBD::Pg and it is the first and primary module you should use when interacting with PostgreSQL. The compatibility mode module DBD::PgPP was created by some other person and is useful if you can't use the standard DBD::Pg module.
| [reply] |
Pg seems to be a more specific module, something specific tailored for Postgres
Sure, DBI is not "specifically tailored" for PostgreSQL, but DBD::PgPP is. The DBI simply specifies the interface; the DBD is where the rubber meets the road. The only thing that Pg could have is a more PostreSQL-friendly interface. Though it's been my experience that the interface enforced by DBI is quite flexible, and very nice. I've never had a problem using it with PostgreSQL.
As far as specific things that Pg does behind the scenes that PgPP does not, I don't know. As davidrw indicated, Pg is significantly older. It probably hasn't seen much maintenance, and likely doesn't have any significant advantages in terms of implementation, but if it does, it would be possible to move those bits into DBD::Pg and DBD::PgPP, where applicable.
So, my reply can be boiled down to: Pg might do some things better than DBD::PgPP, but there's no inherent reason that it should.
| [reply] |