> On Tue, Apr 27, 2004 at 12:14:08AM +0200, H.Merijn Brand wrote:
> > On Mon 26 Apr 2004 17:31, "Dean Arnold" <[EMAIL PROTECTED]> wrote:
> > > > On Sat 24 Apr 2004 21:38, "Dean Arnold" <[EMAIL PROTECTED]> wrote:
>
> > > > > $sth->{TYPE}->[0] == SQL_DECIMAL,
> > > > > $sth->{PRECISION}->[0] == 10,
> > > > > $sth->{SCALE}->[0] == 2 => $sth->{TYPE_STRING}->[0] =
> > > > > 'DECIMAL(10,2)'
>
> > > 1) Drivers should provide their own TYPE_STRING values, presumably in their
> > > native platforms' format
> > >
> > > 2) For any driver that doesn't provide TYPE_STRING, but *does* provide
> > > type_info_all(),
> > > DBI layer would generate TYPE_STRING from the information from type_info_all(),
> > > {TYPE}, {PRECISION}, {SCALE}
> > >
> > > 3) For drivers that provide neither TYPE_STRING nor type_info(), DBI generates
> > > TYPE_STRING from 'standard' type names and {TYPE}/{PRECISION}/{SCALE}
> >
> > This is more clear to me, and I think it covers my request.
>
> 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...
Dean Arnold
Presicient Corp.
www.presicient.com
