On Mon, Mar 24, 2003 at 09:59:53AM -0600, Paul DuBois wrote:
> At 12:52 +0000 3/24/03, Tim Bunce wrote:
> >On Mon, Mar 24, 2003 at 12:04:13AM -0500, Rudy Lippan wrote:
> > >    and  '/', '\', and '.' can not be used in a
> >>    quoted identifier.  Should quote_identifier() thow an error if it gets
> >>    data that it cannot quote?  -- I think it should, but I just wanted to
> >>    some feed back.
> >
> >It's generally best not to second-guess the server...
> >
> >mysql> create table foo (`foo.bar` int);
> >Query OK, 0 rows affected (0.09 sec)
> >mysql> desc foo;
> >+---------+---------+------+-----+---------+-------+
> >| Field   | Type    | Null | Key | Default | Extra |
> >+---------+---------+------+-----+---------+-------+
> >| foo.bar | int(11) | YES  |     | NULL    |       |
> >+---------+---------+------+-----+---------+-------+
> >
> >For table names (which can't contain '.' etc) the server will
> >generate an error if and when apprioriate.
> 
> The exact rules for MySQL identifiers are:
> 
> Database and table names cannot contain '\', '/', or '.' characters.
> Column and index names can.

Thanks. My point was that there is no great need to encode a copy of
those (current) rules into the driver. The server error will suffice.

> >A couple of other items I've remembered recently...
> >
> > - I'd really like to see mysql_client_found_rows=1 being the default.
> >
> >   With mysql_client_found_rows off, normal application code can't
> >   tell the difference between an update that failed to match a row
> >   and one that matched a row but didn't actually change anything.
> >
> >   It's a significant inconsistency with other drivers. I don't know
> >   of any other driver that return a rows *physically changed* count.
> >   This is going to be an issue with future versions of Class::DBI
> >   because it will treat $obj->update() updating 0 rows as an error.
> 
> Mark Matthews' JDBC driver, MySQL Connector/J, operates in "found rows"
> mode by default, because that is required by the JDBC spec.  JDBC is,
> I believe, modelled after ODBC.  Is DBI as well?

Yes. And most people and applications expect that standard behaviour.

Tim.

Reply via email to