Re: [DB] returning typed data when fetching rows

Hi, Guillaume, I can't speak for PEAR Group, or even the majority of PEAR developers. I can speak from my own experience, though, so here goes. :-)

But I must agree with regard to supporting the "array" data type; I don't think the PEAR abstraction libraries can reasonably be expected to handle them all. E.g., I think PG has a "geo" data type for latitude/longitude coordinates; in the same manner MySQL has its own special types (enum, set).

Why not? So if I need to use even just one proprietary feature, why do I have to hack it myself? Isn't PEAR about making developers' job easier by providing high quality code?

The short answer to the overall question ("Why no support for specific feature X in specific database Z?") is: Because there are too many features from too many different databases. Everybody has their favorite RDBMS, and everybody has their favorite set of features from it. The purpose of PEAR [DB|MDB|MDB2] is to find the commonalities between those engines and abstract them as well as possible in specific ways. If a feature is not common, or mostly-common, among the supported databases, then that feature cannot reasonably be abstracted because the feature simply cannot be emulated easily or well in other databases. So while PEAR is "about making developers' job easier by providing high quality code" it is not necessarily about predicting the need for support of a non-common feature of a specific database.

I believe that proprietary features should be supported by abstraction layers, provided that the developer is informed that it is, in fact, proprietary, and that this particular portion of code won't be easily portable.

Then it wouldn't be "abstracted" very well. ;-) Personally, I know how difficult it is to write any sort of abstraction layer; DB_Table attempts to find the lowest common denominator of its supported databases and work within those limits, but even that has its drawbacks (both design-wise and practice-wise ;-). I'm not sure if this helps you or not; certainly your patches to any of the existing PEAR packages would be welcome if they fit the goals of the package leads. Good luck. :-) -- Paul M. Jones Savant: the simple alternative to Smarty for PHP. http://phpsavant.com/ DB_Table: build RDBMS tables and XHTML forms in one PHP class. http://wiki.ciaweb.net/yawiki/index.php?area=DB_Table Yawiki: a collaborative online documentation system. http://yawiki.com/ Yawp: a single-file foundation for PHP applications. http://phpyawp.com/