Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
( 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
[PHP-DEV] php-src in Eclipse CDT
Hi, Now, i'm using Eclipse CDT (C/C++ Development Tools) and Subclipse. I have a Project (no C Project) from the checkout of the PHP SVN. I modify files, I can create/apply path easly, i'm happy. But, to build, i'm using the console, "make && sudo make install". Is it possible that when I save into Eclipse it build automatically PHP ? Thanks. Samuel. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Pierre Joye ha scritto: > On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE wrote: >> This is a bit complicated and very different ! Actually, each database >> works as it want and it may be better to use different functions for >> each driver. > > That defeats the whole purpose of PDO. The meaning of each message > will indeed different, but if one needs to call different APIs for > each driver, I doubt anyone will ever use them. Quoting my chat with Rasmus in Verona earlier this year: "PDO is a database driver abstraction layer, not a database abstraction layer", or something along the lines, but I see your point ;) However, I've been thinking about this a bit more and I think that the different "message" meanings can be summarised like this: * MySQL raises warnings, esp. when not running in strict mode * Oracle uses them as a custom way to deliver messages/data * PostgreSQL being a bit of both worlds: informational + custom By all means, I like the idea of a unified "message" API, but do we really need the syntactic sugar (and development effort)? MySQL and Oracle drivers can already access them with a standard PDO::query() call. Only PgSQL notices require a special treatment because they are currently discarded. I guess this is becoming more philosophical question: is the base PDO class intended to only have common and portable functionalities and leve everything else to the drivers or should it also try and group other similar features to be more consistent even though not likely to be portable? Also I guess that mixing and matching names could be confusing: an experienced Oracle developer using "dbms_output" would hardly imagine that they can be fetched by calling getMessages() just by taking a quick look to the documentation. Same goes for a Postgres developer who can easily understand what pg_last_notice() does and would probably not associate the familiar notice concept with getMessages. Sorry for the long post, it's just my 2 cents. Cheers -- Matteo Beccati -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
hi, The idea is good and matches my thoughts on this topic. Some comments: - no driver specific API, so getNotices instaed of getNotices - common attribute name as well and maybe a better naming ATTR_LOG_NOTICES? 5.2 is also only for security fixes. Can you try to produce a patch against 5.3 and trunk please? Cheers, On Wed, Oct 7, 2009 at 3:29 PM, Samuel ROZE wrote: > Le mercredi 07 octobre 2009 à 07:57 +0200, Samuel ROZE a écrit : >> Well, i've show the patch this morning... It's great ! The allocation of >> the HashTable when use setAttribute might not be really a good job but >> other, in my mind, is ! >> >> See you afternoon for PHP 5.2 path. :-) > > Well, I've done a patch for PHP 5.2 branch: > http://www.d-sites.com/wp-content/uploads/2009/10/pdo_pgsql_notices_php5.2.patch > > It is working but there are two memory leaks when running with CGI: > > [Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php' > /usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(105) : Freeing > 0x01C43A80 (24 bytes), script=pgsql_notice.php > [Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php' > /usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(55) : Freeing > 0x01C43AF0 (22 bytes), script=pgsql_notice.php > === Total 2 memory leaks detected === > > Joined, the pgsql_driver.c file. > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Actually, PDO want to abstract the communication between the Database and PHP. In "the communication" there are the connection and the querying of tables which raise errors and notices (for many Databases drivers). So, in my mind, it will be a great job to standardise recuperation of theses...although the method to get them is different, that is "the communication" ! Samuel. Le mercredi 07 octobre 2009 à 15:49 +0200, Matteo Beccati a écrit : > Pierre Joye ha scritto: > > On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE > > wrote: > >> This is a bit complicated and very different ! Actually, each database > >> works as it want and it may be better to use different functions for > >> each driver. > > > > That defeats the whole purpose of PDO. The meaning of each message > > will indeed different, but if one needs to call different APIs for > > each driver, I doubt anyone will ever use them. > > Quoting my chat with Rasmus in Verona earlier this year: "PDO is a > database driver abstraction layer, not a database abstraction layer", or > something along the lines, but I see your point ;) > > However, I've been thinking about this a bit more and I think that the > different "message" meanings can be summarised like this: > > * MySQL raises warnings, esp. when not running in strict mode > * Oracle uses them as a custom way to deliver messages/data > * PostgreSQL being a bit of both worlds: informational + custom > > By all means, I like the idea of a unified "message" API, but do we > really need the syntactic sugar (and development effort)? MySQL and > Oracle drivers can already access them with a standard PDO::query() > call. Only PgSQL notices require a special treatment because they are > currently discarded. > > I guess this is becoming more philosophical question: is the base PDO > class intended to only have common and portable functionalities and leve > everything else to the drivers or should it also try and group other > similar features to be more consistent even though not likely to be > portable? > > Also I guess that mixing and matching names could be confusing: an > experienced Oracle developer using "dbms_output" would hardly imagine > that they can be fetched by calling getMessages() just by taking a quick > look to the documentation. Same goes for a Postgres developer who can > easily understand what pg_last_notice() does and would probably not > associate the familiar notice concept with getMessages. > > Sorry for the long post, it's just my 2 cents. > > > Cheers -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Samuel ROZE ha scritto: > Le mercredi 07 octobre 2009 à 15:47 +0200, Pierre Joye a écrit : >> 5.2 is also only for security fixes. Can you try to produce a patch >> against 5.3 and trunk please? > > There's the patch of Matteo Beccati at this address for PHP 5.3: > http://www.beccati.com/misc/php/pdo_pgsql_notices_php5_3.patch > > I can make another for the trunk, why not :-). I'll probably try to make > this functionality as global today or tomorrow. Cool, I'll leave that to you and I'll make myself available for reviewing. Cheers -- Matteo Beccati -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
hi, On Wed, Oct 7, 2009 at 3:49 PM, Matteo Beccati wrote: > By all means, I like the idea of a unified "message" API, but do we > really need the syntactic sugar (and development effort)? MySQL and > Oracle drivers can already access them with a standard PDO::query() > call. Only PgSQL notices require a special treatment because they are > currently discarded. > > I guess this is becoming more philosophical question: is the base PDO > class intended to only have common and portable functionalities Yes, and I consider this request as something we could have in a portable way. > Also I guess that mixing and matching names could be confusing: an > experienced Oracle developer using "dbms_output" would hardly imagine > that they can be fetched by calling getMessages() just by taking a quick > look to the documentation. Same goes for a Postgres developer who can > easily understand what pg_last_notice() does and would probably not > associate the familiar notice concept with getMessages. That's the problem when dealing with many databases. Messages can be confusing, notices could be better. In the end it is a documentation matter and if users do not read the manual (experienced or not) there will be no good name anyway ... :). -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Le mercredi 07 octobre 2009 à 15:47 +0200, Pierre Joye a écrit : > The idea is good and matches my thoughts on this topic. > > Some comments: > - no driver specific API, so getNotices instaed of getNotices It was discuss, it need hours to implement this method to all drivers... > - common attribute name as well and maybe a better naming ATTR_LOG_NOTICES? Why not, but it must be in the same time that the last question > 5.2 is also only for security fixes. Can you try to produce a patch > against 5.3 and trunk please? There's the patch of Matteo Beccati at this address for PHP 5.3: http://www.beccati.com/misc/php/pdo_pgsql_notices_php5_3.patch I can make another for the trunk, why not :-). I'll probably try to make this functionality as global today or tomorrow. Thanks for your feedback. Samuel. > Cheers, > > On Wed, Oct 7, 2009 at 3:29 PM, Samuel ROZE wrote: > > Le mercredi 07 octobre 2009 à 07:57 +0200, Samuel ROZE a écrit : > >> Well, i've show the patch this morning... It's great ! The allocation of > >> the HashTable when use setAttribute might not be really a good job but > >> other, in my mind, is ! > >> > >> See you afternoon for PHP 5.2 path. :-) > > > > Well, I've done a patch for PHP 5.2 branch: > > http://www.d-sites.com/wp-content/uploads/2009/10/pdo_pgsql_notices_php5.2.patch > > > > It is working but there are two memory leaks when running with CGI: > > > > [Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php' > > /usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(105) : Freeing > > 0x01C43A80 (24 bytes), script=pgsql_notice.php > > [Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php' > > /usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(55) : Freeing > > 0x01C43AF0 (22 bytes), script=pgsql_notice.php > > === Total 2 memory leaks detected === > > > > Joined, the pgsql_driver.c file. > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
On 07.10.2009, at 15:49, Matteo Beccati wrote: Pierre Joye ha scritto: On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE wrote: This is a bit complicated and very different ! Actually, each database works as it want and it may be better to use different functions for each driver. That defeats the whole purpose of PDO. The meaning of each message will indeed different, but if one needs to call different APIs for each driver, I doubt anyone will ever use them. Quoting my chat with Rasmus in Verona earlier this year: "PDO is a database driver abstraction layer, not a database abstraction layer", or something along the lines, but I see your point ;) However, I've been thinking about this a bit more and I think that the different "message" meanings can be summarised like this: * MySQL raises warnings, esp. when not running in strict mode * Oracle uses them as a custom way to deliver messages/data * PostgreSQL being a bit of both worlds: informational + custom By all means, I like the idea of a unified "message" API, but do we really need the syntactic sugar (and development effort)? MySQL and Oracle drivers can already access them with a standard PDO::query() call. Only PgSQL notices require a special treatment because they are currently discarded. I guess this is becoming more philosophical question: is the base PDO class intended to only have common and portable functionalities and leve everything else to the drivers or should it also try and group other similar features to be more consistent even though not likely to be portable? Also I guess that mixing and matching names could be confusing: an experienced Oracle developer using "dbms_output" would hardly imagine that they can be fetched by calling getMessages() just by taking a quick look to the documentation. Same goes for a Postgres developer who can easily understand what pg_last_notice() does and would probably not associate the familiar notice concept with getMessages. yeah .. its certainly a valid question. we have stuff like lastInsertId(), which depending on the driver either gets the current value of a sequence or the last id generated for the connection. so going by that example unifying things under a common API makes sense if that means that it makes writing portable code easier. so if pgsql and mysql both give warnings that "paranoid" developers might want to interpret as an error whatever, then it seems to make sense to unify this under a common API .. so the key test is not to unify messaging API's but more unify things that are semantically similar. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Le mercredi 07 octobre 2009 à 07:57 +0200, Samuel ROZE a écrit :
> Well, i've show the patch this morning... It's great ! The allocation of
> the HashTable when use setAttribute might not be really a good job but
> other, in my mind, is !
>
> See you afternoon for PHP 5.2 path. :-)
Well, I've done a patch for PHP 5.2 branch:
http://www.d-sites.com/wp-content/uploads/2009/10/pdo_pgsql_notices_php5.2.patch
It is working but there are two memory leaks when running with CGI:
[Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php'
/usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(105) : Freeing
0x01C43A80 (24 bytes), script=pgsql_notice.php
[Wed Oct 7 15:20:10 2009] Script: 'pgsql_notice.php'
/usr/src/php-5.2.10/ext/pdo_pgsql/pgsql_driver.c(55) : Freeing
0x01C43AF0 (22 bytes), script=pgsql_notice.php
=== Total 2 memory leaks detected ===
Joined, the pgsql_driver.c file.
/*
+--+
| PHP Version 5|
+--+
| Copyright (c) 1997-2009 The PHP Group|
+--+
| This source file is subject to version 3.01 of the PHP license, |
| that is bundled with this package in the file LICENSE, and is|
| available through the world-wide-web at the following url: |
| http://www.php.net/license/3_01.txt |
| If you did not receive a copy of the PHP license and are unable to |
| obtain it through the world-wide-web, please send a note to |
| lice...@php.net so we can mail you a copy immediately. |
+--+
| Authors: Edin Kadribasic |
| Ilia Alshanestsky |
| Wez Furlong|
+--+
*/
/* $Id: pgsql_driver.c 272374 2008-12-31 11:17:49Z sebastian $ */
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "php.h"
#include "php_ini.h"
#include "ext/standard/info.h"
#include "pdo/php_pdo.h"
#include "pdo/php_pdo_driver.h"
#undef PACKAGE_BUGREPORT
#undef PACKAGE_NAME
#undef PACKAGE_STRING
#undef PACKAGE_TARNAME
#undef PACKAGE_VERSION
#include "pg_config.h" /* needed for PG_VERSION */
#include "php_pdo_pgsql.h"
#include "php_pdo_pgsql_int.h"
#include "zend_exceptions.h"
static char * _pdo_pgsql_trim_message(const char *message, int persistent)
{
register int i = strlen(message)-1;
char *tmp;
if (i>1 && (message[i-1] == '\r' || message[i-1] == '\n') && message[i] == '.') {
--i;
}
while (i>0 && (message[i] == '\r' || message[i] == '\n')) {
--i;
}
++i;
tmp = pemalloc(i + 1, persistent);
memcpy(tmp, message, i);
tmp[i] = '\0';
return tmp;
}
int _pdo_pgsql_error(pdo_dbh_t *dbh, pdo_stmt_t *stmt, int errcode, const char *sqlstate, const char *file, int line TSRMLS_DC) /* {{{ */
{
pdo_pgsql_db_handle *H = (pdo_pgsql_db_handle *)dbh->driver_data;
pdo_error_type *pdo_err = stmt ? &stmt->error_code : &dbh->error_code;
pdo_pgsql_error_info *einfo = &H->einfo;
char *errmsg = PQerrorMessage(H->server);
einfo->errcode = errcode;
einfo->file = file;
einfo->line = line;
if (einfo->errmsg) {
pefree(einfo->errmsg, dbh->is_persistent);
einfo->errmsg = NULL;
}
if (sqlstate == NULL) {
strcpy(*pdo_err, "HY000");
}
else {
strcpy(*pdo_err, sqlstate);
}
if (errmsg) {
einfo->errmsg = _pdo_pgsql_trim_message(errmsg, dbh->is_persistent);
}
if (!dbh->methods) {
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC, "SQLSTATE[%s] [%d] %s",
*pdo_err, einfo->errcode, einfo->errmsg);
}
return errcode;
}
/* }}} */
/* Path for notices: Manage notices */
static void _pdo_pgsql_notice(pdo_dbh_t *dbh, const char *message) /* {{{ */
{
pdo_pgsql_db_handle *H = (pdo_pgsql_db_handle *)dbh->driver_data;
zval *val;
if (H->notices) {
ALLOC_INIT_ZVAL(val);
ZVAL_STRING(val, _pdo_pgsql_trim_message(message, dbh->is_persistent), 0);
zval_add_ref(&val);
zend_hash_next_index_insert(H->notices, &val, sizeof(zval *), NULL);
}
}
/* }}} */
/* Path for notices: Function which initialize notices */
void pdo_pgsql_notice_init(pdo_dbh_t *dbh) /* {{{ */
{
pdo_pgsql_db_handle *H = (pdo_pgsql_db_handle *)dbh->driver_data;
if (H->notices) {
zend_hash_clean(H->notices);
}
}
/* }}} */
static int pdo_pgsql_fetch_error_func(pdo_dbh_t *dbh, pdo_stmt_t *stmt, zval *info TSRMLS_DC) /* {{{ */
{
pdo_pgsql_db_handle *H = (pdo_pgsql_db_handle *)dbh->driver_data;
pdo_pgsql_error_info *einfo = &H->einfo;
if (einfo->errcode) {
add_next_index_long(info, einfo->errcode);
add_next_index_string(info, einfo->errmsg, 1);
}
return 1;
}
/* }}} */
/* {{{ pdo_pgsql_create_lob_stream */
static
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Le mercredi 07 octobre 2009 à 13:30 +0200, Pierre Joye a écrit : [...] > > This is a bit complicated and very different ! Actually, each database > > works as it want and it may be better to use different functions for > > each driver. > > That defeats the whole purpose of PDO. The meaning of each message > will indeed different, but if one needs to call different APIs for > each driver, I doubt anyone will ever use them. You're right... If developers are motivated to do that, it'll be a really great thing ! :-) > Cheers, -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
On Wed, Oct 7, 2009 at 1:27 PM, Samuel ROZE wrote: > Le mercredi 07 octobre 2009 à 09:06 +0200, Matteo Beccati a écrit : >> From what I could see, things get a bit more complicate on the code side: >> >> PgSQL: >> 1. Set a notice processor callback >> 2. Clear the notice buffer before a query >> 3. Asynchronously buffer notices inside the callback >> 4. Set a no-op processor callback >> >> MySQL: >> 1. Call mysql_warning_count() after a succesful query >> 2. if the result is non-zero, execute "SHOW WARNINGS" and fetch the results >> >> Oracle: >> 1. Enable output buffering >> 2. Fetch the buffer after a successful query >> 3. Clear the buffer >> 4. Disable output buffering >> >> Adding generic hooks/functions will also require a PDO API version bump. > > This is a bit complicated and very different ! Actually, each database > works as it want and it may be better to use different functions for > each driver. That defeats the whole purpose of PDO. The meaning of each message will indeed different, but if one needs to call different APIs for each driver, I doubt anyone will ever use them. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Le mercredi 07 octobre 2009 à 09:06 +0200, Matteo Beccati a écrit : > From what I could see, things get a bit more complicate on the code side: > > PgSQL: > 1. Set a notice processor callback > 2. Clear the notice buffer before a query > 3. Asynchronously buffer notices inside the callback > 4. Set a no-op processor callback > > MySQL: > 1. Call mysql_warning_count() after a succesful query > 2. if the result is non-zero, execute "SHOW WARNINGS" and fetch the results > > Oracle: > 1. Enable output buffering > 2. Fetch the buffer after a successful query > 3. Clear the buffer > 4. Disable output buffering > > Adding generic hooks/functions will also require a PDO API version bump. This is a bit complicated and very different ! Actually, each database works as it want and it may be better to use different functions for each driver. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
hi, On Wed, Oct 7, 2009 at 9:06 AM, Matteo Beccati wrote: > Christopher Jones wrote: >> Lukas Kahwe Smith wrote: >>> >>> On 07.10.2009, at 08:09, Matteo Beccati wrote: >>> Christopher Jones ha scritto: > > Could you use the new PG specific attribute to enable them > but make them output/handled by the existing error/exception > interface? That's what I originally thought. But there can be multiple notices triggered by a single query and they shouldn't make the query fail (i.e. throwing an exception would be awkward for a successful query). >>> >>> >>> MySQL has similar notices. Like when stuff gets truncated etc. >>> I also think that using the current "error modes" is probably not >>> ideal. Or rather these arent exception worthy, and they should >>> obviously not return false either. >> >> Is there a common interface that would suit both MySQL & Postgres usage? > > From the user perspective I'd say yes. We can surely make generic > attributes and methods to deal with warnings/notices/dbms_output. > > From what I could see, things get a bit more complicate on the code side: > > PgSQL: > 1. Set a notice processor callback > 2. Clear the notice buffer before a query > 3. Asynchronously buffer notices inside the callback > 4. Set a no-op processor callback > > MySQL: > 1. Call mysql_warning_count() after a succesful query > 2. if the result is non-zero, execute "SHOW WARNINGS" and fetch the results > > Oracle: > 1. Enable output buffering > 2. Fetch the buffer after a successful query > 3. Clear the buffer > 4. Disable output buffering > > Adding generic hooks/functions will also require a PDO API version bump. 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. 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. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
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. Cheers -- Matteo Beccati -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
On 07.10.2009, at 08:09, Matteo Beccati wrote: Christopher Jones ha scritto: Could you use the new PG specific attribute to enable them but make them output/handled by the existing error/exception interface? That's what I originally thought. But there can be multiple notices triggered by a single query and they shouldn't make the query fail (i.e. throwing an exception would be awkward for a successful query). MySQL has similar notices. Like when stuff gets truncated etc. I also think that using the current "error modes" is probably not ideal. Or rather these arent exception worthy, and they should obviously not return false either. regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PDO PgSQL: _pdo_pgsql_notice
Christopher Jones wrote: > Lukas Kahwe Smith wrote: >> >> On 07.10.2009, at 08:09, Matteo Beccati wrote: >> >>> Christopher Jones ha scritto: Could you use the new PG specific attribute to enable them but make them output/handled by the existing error/exception interface? >>> >>> That's what I originally thought. But there can be multiple notices >>> triggered by a single query and they shouldn't make the query fail (i.e. >>> throwing an exception would be awkward for a successful query). >> >> >> MySQL has similar notices. Like when stuff gets truncated etc. >> I also think that using the current "error modes" is probably not >> ideal. Or rather these arent exception worthy, and they should >> obviously not return false either. > > Is there a common interface that would suit both MySQL & Postgres usage? >From the user perspective I'd say yes. We can surely make generic attributes and methods to deal with warnings/notices/dbms_output. >From what I could see, things get a bit more complicate on the code side: PgSQL: 1. Set a notice processor callback 2. Clear the notice buffer before a query 3. Asynchronously buffer notices inside the callback 4. Set a no-op processor callback MySQL: 1. Call mysql_warning_count() after a succesful query 2. if the result is non-zero, execute "SHOW WARNINGS" and fetch the results Oracle: 1. Enable output buffering 2. Fetch the buffer after a successful query 3. Clear the buffer 4. Disable output buffering Adding generic hooks/functions will also require a PDO API version bump. Cheers -- Matteo Beccati -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
