Changing Modules in Bad Code

[Kozz]

Most esteemed monks:

I have been asked to evaluate some CGI code for revisions. The code in question is written *horribly*, without "use strict" in most of them, no modularization or custom packages for easy configuration, lots of HTML inside the CGI scripts.

It also uses the somewhat antiquated Postgres module (which I dislike). However, I've been asked to update these scripts to use the DBI module (which I am familiar with -- I think it works with Postgres?).

Now I'm wrestling with two possible solutions, and would like your opinions.

I've been told that I should not go to any heroic efforts to make all the code "better", because so long as it is working, they don't want to spend the money rewriting it from scratch. Basically, make it use the new DBI module, keep it working, but not much else.

I thought about two different solutions:

1. The straight-forward editing of every single perl CGI script, replacing "use Postgres" with "use DBI", then fixing up all the code to use DBI methods for connecting, executing, fetching results, error handling
2. OR, the more challenging (but maybe easier, too??) of writing my own "Postgres" module that actually acts as a *wrapper* to the current DBI module

The first one could be done, but would be exceedingly tedious, and there would surely be a higher chance of missing some code somewhere, or messing up other things as I try to "fix" the code.

The second one sounds more intriguing, so that if I wrote wrapper methods that made all the proper DBI method calls, the "use Postgres" would then call *my* module instead, but everything would go through the DBI module.

The drawback of #2 is that I have never found the need / excuse to create my own package or module, ever. I don't (yet) know how to do it. I've looked at perltoot and perlmod (the latter of which is by no means a "how-to" document IMO).

I'm not sure what sort of problems I would be making for myself if I used solution #2. I would vastly appreciate all monks' advice offered.