So to preface this, I've been working on getting the latest versions of these modules running on PostgreSQL, and in the process I've run into several issues which, I think, I've touched up in relatively clean ways.

'INSERT INTO * SET' queries don't work on PostgreSQL - all have been replaced with equivalent 'INSERT INTO ()VALUES()' queries - should work just fine on MySQL

'db_affected_rows()' is set to 0 after a SELECT query in PostgreSQL, (since the actual implementation asks the database "how many modified rows?") - a more compatible way to check if a database query contains something is just test the result directly... you can use a straight 'if ($result)' though I've patched in '!empty($result)' which works too - I think there's also some D6 DB functions for this too, but... it works? :p

And this was a really fun one: $edit doesn't get cleaned up in hook_user in the current module versions, leaving a lot of extra junk in the user data field... at times the modules will actually use this junk data due to some user_access conflicts, which, I think, is the cause of several of the posted intermittent and otherwise bizarre issues (I'm looking at you, Affiliates module ;)

The replacement access checking code might be a bit over the top if access is checked again when an affiliate is actually used but it works... the code in question is in ms_affiliates user_load hook - it probably doesn't *really* need a user_access check at all, that should be checked when *using* the affiliate (and is, I believe).
Also, since user_access is checked on the parent for generating user_load affiliate data, I touched up the admin panel to do a straight ms_affiliates_get_affiliate (so the admin can see the affiliate setting even if it's not valid due to expired membership etc) - which could be more efficiently done using affiliate_aid if the access checks were removed.

I also added an access check to allow administrators who can set affiliates (and create users) to be able to bypass the registration lockdown, imposed by requiring an affiliate id for registration, since they can set the affiliate id... (a feature I particularly needed, perhaps this should be a unique access category though?)

The patches are a bit long to paste here:
http://dev2.rewardingplanet.com/sites/default/files/ms/ms_core.patch
http://dev2.rewardingplanet.com/sites/default/files/ms/ms_affiliates.patch
http://dev2.rewardingplanet.com/sites/default/files/ms/ms_membership.patch
http://dev2.rewardingplanet.com/sites/default/files/ms/ms_clickbank.patch

For anyone interested in getting these modules running in PostgreSQL, you'll also need a few custom functions, unix_timestamp, from_unixtime and convert_date_format in particular (these could actually be ported to PostgreSQL friendly queries in code too, but I didn't bother, since the DB functions work fine as is and might save me some trouble in the future) - if anyone's interested I can post those here, but they were fairly basic stuff...

I also manually have my ms_orders full_name field set to accept null data, which is definitely required to make things run on PostgreSQL (which is set in ms_core.install:99 I think?) but I left that out of the patches, since I'm not quite so sure about the why surrounding it...