( Having stripped 6 people from the reply list ... )
Matteo Beccati wrote:
Pierre Joye ha scritto:
Having them part of the PHP errors is counter intuitive and add extra
work for little gain. Mysql being the most cleaner way to do it at
this stage as it does not interfer with php code at all.
Yes. That's exactly why I added a new method, although driver specific.
Could we make it independent from php's errors (be notices or
warnings)? For example to add a PDO statement method to fetch these
messages after having executed or prepared a query, getMessages for
example.
The PDO::exec(), method doesn't return a PDOStatement. With exec being
the most common way to execute DDL or DML queries, the ones that are
more likely to return a notice or warning.
Hopefully now we can get back to addressing the areas where PDO is
simply not up to the job? I'm sure half of the reason that there has
been no real rush to support PDO from some areas is simply because to
many of the driver specific elements are missing, and saying that we
just need to add them for each driver still seems wrong to me. Currently
the best way to handle a specific database is it's own generic driver,
and if using PDO, one normally ends up loading the relevant generic one
when the holes start to appear? The database engines are getting more
and more complex, and while PDO sort of provides a flat playing field
for data (one with it's own holes ) it still has some way to go to
provide a flatter interface to database extensions such as 'notice' ?
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
