It looks like a false alarm. I can't reproduce it outside Class::DBI
(using mysql client, or DBD::mysql, using v3 or v4) so I need to
dig deeper into Class::DBI to see what's happening there.
Tim.
On Mon, Mar 03, 2003 at 06:39:01PM -0600, Paul DuBois wrote:
> At 0:18 +0000 3/4/03, Tim Bunce wrote:
> >I've discovered that DBD::mysql will return "tablefoo.fieldbar" as
> >the NAME of the field in a select like:
> >
> > SELECT tablefoo.fieldbar FROM tablefoo
>
> That's not what I observe. Is this a recent change in the MySQL C client
> library? The library has not returned a table name before, because
> the table name is in a separate member of the MYSQL_FIELD structure.
>
> >
> >It does that simply because that's what the underlying mysql client
> >API tell it is the name of the field.
> >
> >I believe this is very rare (I know of no others drivers that do that)
> >and I'm considering changing the DBI specification to clarify that NAME
> >should only contain the fieldname.
> >
> >I appreciate that there's a loss of information here and that
> >statements like this:
> >
> > SELECT table1.field, table2.field FROM table1, table2 WHERE ...
> >
> >will return the same NAME value for both fields.
> >
> >However, I'm currently of the opinion that removing the table name
> >to make NAME be consistent with the behaviour of other drivers is
> >of greater benefit than retaining the table name.
> >
> >I'd welcome any examples of code that *relies* in the table name
> >being present in the NAME attribute and can't easily be changed.
> >
> >Note that in the specific case of DBD::mysql, the table name of
> >each field is also availble in the $sth->{mysql_table} attribute,
> >so any application that needs the table name for each field can
> >still get it.
> >
> >Tim.
>
