Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase

John, in addition to the list you posted, there's - inconsistent/incomplete metadata support. it would be nice, for example if the MySQL extension would be more precise about a field type than "string", etc i tried hard and failed to describe why i'd want to start a C based DB library, and you have described the issues better than ive done in the past weeks. im less particular on how things look at the PHP level (though i have definite preferences), than to provide a general framework in C for user-level code to build on. there are lots of issues not addressed or handled in an ad-hoc way in the database extensions that have to be addressed at a lower level, and doing so presents unique opportunities to other module writers who need DB support in their extensions. i'll leave web developers to fight over flavors of ice-cream - i'm happy to churn the milk. l0t3k BTW - i think i'll start using the term Unified API. seems Rorschach (sp?) enough to please most folk. John Lim <heyjohnlim@yahoo.com> wrote in message news:20011120165916.48759.qmail@pb1.pair.com... > Actually the common code is already available: it is the > database extension API's. But most of the problems are > in the database extension APIs also, and our work is fixing > their mistakes. > > Examples: > -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase, > when everyone else is using lowercase. > > -Magic Quotes murders our quoting, and what about magic quotes > sybase which happens to be for interbase and sql server too! > > -Postgresql does not have an error number to return. And there is > no pg_insert_id() either. > > -Interbase's API is missing an arm and a leg, and whether it is > the left or right arm missing is not documented anywhere. > > -All extensions should support blobs like Oracle, with a fetch mode > that makes "SELECT blob FROM table" transparent with no special > coding. > > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... > > John