On Tue, Apr 27, 2004 at 12:09:37PM -0700, Dean Arnold wrote: > > > > > > I'd consider a patch, with documentation and tests. > > > > > > Tim. > > > > I started coding such a patch, then started looking around in DBI as to where > > to "inject" it, and can't seem to find a nice/clean place to put it. AFAIK, > > the only place DBI has a chance to 'meddle' with the driver's prepare() > > is in the _new_sth() call, but the driver may not have all its > > TYPE/NAME/etc. attributes available at that point. > > > > So either (a) I have to force every prepare() to go thru the DBI layer > > to call the driver prepare so I can validate TYPE_STRING exists > > when the driver prepare() is done, or (b) I have to create a tie for it > > somehow ? Or is it safe to assume > > that drivers are well behaved enough to call SUPER::FETCH() inside > > DBD::xxx::st::FETCH() if the requested attribute isn't recognized ? > > > > And, BTW, where the heck is the FETCH code for the DBD::_::st ? > > > > If anyone can provide some pointers on how to patch into that bit of code, > > I'd be much obliged... > > Umm, OK, I think I figured part of the answer...for PP DBI, FETCH() is in > DBI::PurePerl, but for mainstream DBI, its in XS code, yes ? > That latter throws in some wrinkles...
Ignore that for now. Just write it as a perl sub and we can look at integrating it if/when we're all happy with what it does. > Also, can anyone point me to a copy of ISO/ANSI SQL std. that describes > the type characteristics of some of the newer/more complicated types, > esp. REF, ARRAY, MULTISET, UDT, LOCATOR, ROW, and the INTERVAL > items as well (I know how my DBMS flavor handles INTERVAL declarations, but > am not certain what the "standard" is). Specifically, I'm looking for which > types have precision and scale, and where those items would be applied > eg, "DECIMAL(precision, scale)" vs. > "INTERVAL HOUR(precision) TO SECOND(scale)" > > (Is that how other drivers use PRECISION and SCALE with INTERVAL types ?) I was wondering how soon you'd start facing the more tricky cases :) Tim.
