On Tue, Aug 10, 2004 at 04:28:39PM -0400, Jeff Urlwin wrote:
>
> > Comments welcome.
>
> Just some random thoughts that came from reading this.
>
> What about Multiple result set statements/more_results? (i.e. select * from
> foo; select * from bar; or calling stored procs which have multiple
> statements within them as per Sybase & SQL*Server, etc)
Good point. An oversight. I'll add that in.
> > =head2 Unicode
> >
> > Use of Unicode with the DBI is growing rapidly. The DBI could
> > do more to help drivers support Unicode and help applications
> > work with drivers that don't yet support Unicode directly.
> >
> > * Define expected behavior for fetching data and binding parameters.
> >
> > * Fix 'leaking' of UTF8 flag from one row to the next.
>
> Hmmmm....Am I missing something here, but wouldn't a column that has UTF8
> data *always* have UTF8 data within a statement (resetting only between
> statements, such as multiple-result-set statements?
The problem isn't with cols that should be utf8 but with ones that
shouldn't. This is especially a problem with perl 5.6.x where a
variable may get 'promoted' to utf8 just by being used in an
expression with some other utf8 variable. That's more likely with
bind_col.
> > * The popular fetchrow_hashref() method is many times slower than
> > fetchrow_arrayref() because it has to re-get the names of the
> > fields each time. A $h->{FetchHashReuse} attribute would
> > allow the same hash to be reused each time making
> > fetchrow_hashref() about the same speed as fetchrow_arrayref().
>
> Why does it have to re-get the names each time? Why not tie the names in
> with the "more_results" functionality?
"re-get" is just FETCH from the attribute cache, but it adds to the
cost of the fetch method. Then there's alloc'ing the new hash, then
there's loading the keys etc etc. The binding approach used by
fetchrow_arrayref/bind_col would make it all "free" and max speed.
> Yes!
> Double YES!
> Very cool! Esp with threads :)
This is the kind of feedback I like ;-)
> > =head2 Parrot and Perl 6
> >
> [snip]
> >
> > (The project stalled, due to Parrot not having key
> > functionality at the time, and has yet to be restarted.)
>
> Does Parrot yet have the support we need? If so, I must have missed it.
It has method calls, yes. Still weak in some areas (like namespaces)
but that wouldn't stop useful work being done.
Tim.
