Alright, well, I know what the issue is well enough now to know how to fix it, but it's a lot more involved than I was expecting. Short answer is there's no easy way to fix the problems I'm encountering. The one fix I found involves exporting specfic tables, running them through a script, fixing identified errors, and then uploading that table back into the (live) database. Alternatively, since that method means I'm interacting with a live system, I might export them to .csv files, open them in excel, run a series of find & replace commands, and then import them straight to the functional cloned BM MySQL database. Once all the information is together and is proven functional, making it into whatever format is preferred is the next step.
Speaking of which, Tom, the more I look at this, the more research I do, the more I find information saying that SMF was designed to run on MySQL and then adapted to work on PostgreSQL. SMF's own support team says basically any time the discussion comes up that if you can use MySQL or PostgreSQL for SMF, the response is "use MySQL." A topic from last year, a few months before 2.0.11 of SMF was launch ends with the the SMF Support Lead saying "Not that PG is better or worse but the fact is that everything is developed towards MySQL and then "adjusted to work" in PG."
I'm not saying I'm not going to find a way to get this all in PostgreSQL if that's what you really want, assuming I can get the M&F forum database to actually be restorable, but if just trying to get a functional backup of a 2 year old forum is this much of a hassle with a PostgreSQL database behind the forum, I don't even want to imagine what would happen if you tried to do this with a forum the size of the BM and M&F ones combined.
