On Sun, Feb 22, 2004 at 10:53:53AM -0500, Jeff Urlwin wrote:
> > On Sat, Feb 21, 2004 at 08:39:24PM -0500, Jeff Urlwin wrote:
> > > I've been lurking through the $sth->{NAME} issues and it
> > seems to me
> > > that the current behavior of DBD::ODBC is onerous. If
> > dbd_describe()
> > > fails, it croaks (which is what DBD::Oracle does).
> > >
> > > If we return a Nullsv at this point, the end application does *not*
> > > get an undef reference, rather it gets a reference to an
> > empty array.
> >
> > [In general: Never use Nullsv without good reason. Use
> > &sv_undef for undef.]
> >
> > Returning Nullsv tells the Driver.xst code that you "didn't
> > handle this attribute FETCH yourself and you want the DBI to
> > handle it":
> >
> > valuesv = dbd_st_FETCH_attrib(sth, imp_sth, keysv);
> > if (!valuesv)
> > valuesv = DBIc_DBISTATE(imp_sth)->get_attr(sth, keysv);
> > ST(0) = valuesv; /* dbd_st_FETCH_attrib did sv_2mortal */
> >
> > [But looking at the DBI code (dbih_get_attr_k()) I'm not sure
> > why it doesn't get into infinite recursion calling FETCH.
> > I'll look into that.]
> >
> > Anyway, try returning &sv_undef. I think it should also warn(...) if
> > DBIc_WARN(imp_xxh) is true.
>
> Ok -- I did this and it still returns a ref to an empty array.
I don't see how it could. Can you find out what's going on?
> Do you want a similar patch for DBD::Oracle ??
Once the ref to an empty array issue is resolved. Thanks.
Tim.
