RE: [PEAR-DEV] more MDB hacking

> -----Original Message----- > From: Paul Cooper [mailto:pgc@ucecom.com] > > Attached is a patch to fix LOB support in MDB pgsql driver - it now > passes the LOB tests in driver_test.php. This means that the pgsql > driver now passes all the tests in driver_test.php, hence I would > appreciate it if anyone had time to bang on it and check for bugs. Awesome, I will play around with it as well. I don't really have a good testbed for it though. Maybe the binarycloud people have? Since the pgsql driver now passes (once I have done the commits anyways)) the driver_test.php it should work with binarycloud since the driver_test.php tests MDB through the Metabase Wrapper. > > Right now I'll be looking through for CS stuff. Also how strictly should > we enforce contracts, e.g. > > // }}} > // {{{ fetch() > /** > * fetch value from a result set > * > * @param resource $result result identifier > * @param int $row number of the row where the data can be found > * @param int $field field number where the data can be found > * > * @return mixed string on success, a DB error on failure > * > * @access public > */ > function fetch($result, $row, $field) > > > Should we check is_resource($result), is_int($row), is_int($field) and > return errors or do we let the bad data go down to the native functions > to return errors back up? > > I vote for enforcing the contract. > Good question. I think its not really worth it to keep checking of a $result passed to a fetch Method is really a identifier. The performance loss and code bloat is not worth it. The checks that are in place ATM are mostly just ported from Metabase and PEAR DB. Best regards, Lukas