Bob Hunter wrote:
What parts are you having trouble with?
To start with, a DBD::Pg not backward compatible with
Pg. The original program must be back into production
in a few hours; for this to be possible, I have to
instruct the original code to use DBD:Pg, with minimum
or no changes at all.
This is not possible, as you have noted that DBD::Pg is not backward
compatible. I would suggest you implement a modified version of the
code in a testing environment and when the modified version of the new
code passes your code tests, you switch over to using the new code. A
goal of having a production system down for a few hours while you make
all the necessary changes to go from Pg to DBD::Pg is not at all realistic.
To rewrite the application is
out of question. Therefore, I need a cut-through
introduction on how to port a Pg-based program to
DBD::Pg. I cannot possibly go trough the whole gamut
of documents, because I do not have the time for it.
Unfortunately, it is not going to be as simple as a find-and-replace.
And there is not a whole gamut of documents. The DBI docs are the docs
of import (http://search.cpan.org/~timb/DBI-1.53/DBI.pm ). The code
will probably not need to be altered much, but I don't see how you can
possibly hope to convert your old code to new without understanding what
you are going to change it to. You will not need to rewrite the
application, but you will need to make modifications to the way the
application accesses the database. As I mentioned above, I would
present this to your supervisor (if there is one) as a replacement of
the original application. As such, the project will need proper
planning, testing, and time. A few hours (unless this is a pretty
straightforward application that is not mission-critical) is not going
to cut it. So, stick with the Pg version (that is presumably serving
most of your needs), implement and test the new code, and then make the
switch.
Sean
