On Mon, Mar 03, 2003 at 05:46:37PM -0500, Rudy Lippan wrote:
> On Mon, 3 Mar 2003, Tim Bunce wrote:
>
> > $sth = $dbh->prepare("SELECT table.field FROM table"); # note table.field
> > $sth->execute;
> > print "NAME_lc = '$sth->{NAME_lc}->[0]' \n";
> >
> > for the drivers you use?
> >
> > Is it 'field' or 'table.field'?
>
> For DBD::Pg I get field.
>
> > If it's 'table.field', does it only return that if the select
> > explicitl names the table with the field, as in the example above,
> > or does it always return the table even if the field is not qualified
> > with the table name?
> >
> > I've just discovered that DBD::mysql returns 'table.field' and that
> > came as a bit of a surprise.
> >
> > I'm pondering clarifying the DBI spec to ...
> > a) say that drivers should only return the field name, or
> > b) say that NAME may contain the table,
> > but that NAME_lc & NAME_uc won't (because the DBI will remove it), or
>
> b) sounds better.
>
> I can see a) causing problems if you want the driver to remove the
> table name. eg., SELECT 1 AS "table.field", 2 as "This.That";
>
> With b. you are already mucking with the table name so you probably could
> get away with it there.
Actually, after thinking about it, I realise I can't reliably do
that, for exactly the reason you mention. The DBI isn't able to
tell if the dot in a name is the dot that separates a table from a
fieldname, or a fieldname that happens to contain a dot.
The driver is better placed to make that distinction. For DBD::mysql
the data from the server also gives the table name, so if the part
before the dot in the field name matches the table name then it's
very likely that it is the table name (especially as you'd have to
be nuts to put a dot into a fieldname :)
On the other hand, perhaps a dot in the fieldname is so rare (and
daft) that the DBI needn't worry about it itself.
That would then just leave the issue of if any applications depend
on seeing the full name in this situation... I should probably ask
on dbi-users.
Tim.
