On Mon, Mar 03, 2003 at 12:19:33AM -0800, Jonathan Leffler wrote: > > >Scott Hildreth has been working on it from time to time for me. > >He's looking into a Parse::RecDecent implementation now.
["Paging Mr. Hildreth"] > >>2) fetchall_arrayref. > >>The code in Driver_xst.h for fetchall_arrayref seems to be a stub for > >>something to come. I would love to be able to 'get my fingers on' > >>fetchall_arrayref as the Ingres API has methods for returning all rows > >>from a select without involving a cursor - and sligthly faster than a > >>cursor open as well! > > > > > >Ah, what's needed there is very simple - I mentioned it a week or two > >ago... > >All the methods in Driver.xst should have #ifdef dbd_foo around > >them, where dbd_foo if the name of the underlying implementation > >function in your driver code. > > > >See the rows method for the one (and I think) only example currently in > >Driver.xst. > > > >For fetchall_arrayref (and some like it) instead of just an #ifdef > >it needs a #else part that'll contain the current code. There is now a presumption that all exisiting dbd_* functions are implemented by all drivers using Driver.xst. Any new functions will get an #ifdef dbd_foo around them. With regard to fetchall_arrayref, all you need to do is implement dbd_st_fetch() and fetchall_arrayref will use it. > >>3) dbd_db_do > >>is referenced several places: DBD.pm and dbd_xsh.h (and in both the > >>Oracle and ODBC drivers), but all I can find is the declaration - the > >>function and any call to it seems to be missing. Not that I'll miss it, > >>but it does confuse things... > > > >Something like this: > > > >#ifdef dbd_db_do > > > >void > >do(dbh) > > SV * dbh > > CODE: > > D_imp_dbh(dbh); > > ... etc ... > > > >#endif > > > >is missing from Driver.xst. It's been added in DBI 1.33 (thanks to Jonathan). > >>4) STORE_attrib_k and FETCH_attrib_k > >>are only declared in dbd_xsh.h, but are not defined/used anywhere. Are > >>they reserved for future use or??? > > > >Kind of. Vauge ideas (related to hashing attribute names to speed > >up lookup etc) that never got very far, partly because get_info > >took a different, better, direction. You can ignore them. They have been removed now. > >>5) DBIS and DBILOGFP > >>The latest Changes states: > >> Changes for driver authors, not required but strongly recommended: > >> Change DBIS to DBIc_DBISTATE(imp_xxh) [or imp_dbh, imp_sth etc] > >> Change DBILOGFP to DBIc_LOGPIO(imp_xxh) [or imp_dbh, imp_sth etc] > >> Any function from which all instances of DBIS and DBILOGFP are > >> removed can also have dPERLINTERP removed (a good thing). > >> > >>I must have blinked at some time. This is the first time I have noticed > >>'dPERLINTERP' - it is nowhere in the old DBD::Ingres (will that cause > >>things to fail so that I should hurry and put it in, or can I relax and > >>leave things as they are?). > > > >Leave them as they are and tell anyone who uses perl 5.005 threads to > >upgrade. No change. > >>I have changed all references as given above, but could we please have a > >>shorthand for the debug output, as it does look a bit longwinded to write: > >> if (DBIc_DBISTATE(imp_sth)->debug >= 5) > >> PerlIO_printf(DBIc_LOGPIO(imp_sth), ....); > >>all over the place. > > > >That could be > > > > if (DBIc_DEBUGIV(imp_sth) >= 5) > > ... > > > >which is a _little_ better :) Though actually that doesn't do quite > >the right thing. I'll either add a new macro or change that one (or > >what it refers to) to do-the-right-thing. > > > >>Something like: > >> DBI_DEBUG(imp_sth, 5, ....); > >>would be nice - yes I know: patches.... > > > >Doing vararg macros with portable C is a bit tricky. I'd like > >to make that a call back into DBI internals. Maybe something like: > > > > if (DBIc_DEBUGIV(imp_sth) >= 5) > > DBI_TRACE(imp_sth)(...); I'll take a look at this again for a future release. > >>6) DBIh_EVENTx > >>are to be removed. The macroes do nothing now as far as I can see. They now do even less. All just map to &sv_no. Tim.
