> 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.
Do you want a similar patch for DBD::Oracle ??
Regards,
Jeff
>
> > Currently this affects calling sth->NAME on update, delete, most
> > procedure calls, DDL statements, etc.
> >
> > I think I'd like having it return a null reference instead of a
> > reference to an empty array, but I don't know how to manage that at
> > this point.
> >
> > I know there was some discussion on this recently, but I
> couldn't find
> > any conclusion on google. It's been a day of babysitting my three
> > young kids, so please excuse me if I missed it ;)
>
> I need to look back to what I said when this came up before.
> I think there are some changes I could make so that FETCH
> could trigger PrintError/RaiseError. Currently it can't.
I think that would be good.
Reg
