[PHP-DEV] Why not attach XMLReader / XMLWriter to open php streams?
Hi! As documented - and several searches did not lead to a different result - XMLReader and XMLWriter can only work on an URI. That would be a php stream opened and closed by themselves. For several workflows, e.g. with php://temp, it would be nice to be able to "attach" XMLReader/XMLWriter to a pre-opened php stream. I would describe it as letting them work "on a stream" instead of "on an uri". As I didn't find anything about it: Is there a reason for not supporting 'stream resources'? Other extension, like e.g. curl, do. HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Errors, Exceptions et al
Hi! Rasmus Lerdorf wrote: > Yeah, good luck with that. We have been imploring people for 10 years > to not have display_errors on in production with very little success. I agree but am convinced at least part of that problem lies in the default php.ini, which - up to 5.2 - defaulted to display_errors=on! The average user - not configuring anything - got that default and probably got angry about production systems yelling secrets... > press it. As soon as you make this configurable, everyone is going to > configure it differently almost instantly. Configurability already crept into the main distribution - like the veteran display_errors and error_reporting or the newer error_level in intl. I unconditionally prefer one proper concept to uncontrolled growth of differing options. Regards HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Errors, Exceptions et al
Hi!
Christian Schneider wrote:
> leads to another inconsistency: Depending on the hosting provider and/or
> frameworks/modules used you'd have to write different error handlers.
I understand there are widely differing applications for php, that's why
I think backwards-compatibility and common defaults across installations
is a must. Changing defaults system-wide is always risky. In a
shared-hosting situation, the proposed error defaults *must not* be
changed, of course.
However, there are also many single-hosted applications that could
benefit greatly from configurability.
And note I don't only write pro global-configurability, but also
object-wise, like:
$T = new TranslationReader(...);
// say, on error, $a gets set to NULL, no error issued
$a = $T->get('nonexisting');
// change that behaviour for $T ONLY
$T->setErrorBehaviour( ERROR_THROW );
try {
// if ANY error in $T occurs, a corresponding exception is caught
[read many many translation strings]
}
catch( Exception $e ) {}
> One of the nice things about PHP it's easy to learn and knowledge & code
> is (most of the time) transferable amongst different instances of PHP.
And that's how it shall always be. I believe it should even give more
structure in a field where extensions currently fragment and render
php more complicated than it had to be.
Regards
HPO
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Errors, Exceptions et al
Hi! Although I'm new here and I know I'm about to stir up a hornets' nest, please allow me to introduce another error/exception proposal. The problem for me as a php end-user currently is, that no coherent error behaviour in php exists. Core functions only issue errors, intl eg. suppresses all errors (if not enabled), pdo allows suppressing errors, exceptions and errors - but only of level E_WARNING. Whether I prefer suppressing errors, errors or exceptions, I always run into problems: - If I prefer suppressing errors, I cannot do so with any granularity; always setting an resetting the error reporting functions is cumbersome and messy (error-prone). - If I prefer errors, I have to take care of extensions that default on suppressing them (like intl) with probably different methods of enabling errors (ini or per object or...) and frankly, I cannot count on the error level. - If I prefer exceptions, much of php doesn't support them at all and extensions might have different facilities to enable them. ErrorException is not really a solution, as exception information (exception class, previous exception) is lost. I therefore propose to let the *user* decide on the kind of error behaviour; and with some granularity at that. An extension would only ever call a common error function, with at least error code and error message (plus desired error_level and exception class if needed), whereas the "error configuration" not only decides on whether showing the error (now) but also if it is an error or an exception (new). For more details, please have a look at: http://wiki.php.net/rfc/enhanced_error_handling (which is by no means complete or error free itself) Regards HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Are there zend classes "hidden" from php?
Hi! As some already know, I'm using the holidays to prepare a proposal for error handling in extensions (https://saintcyr.oeri.ch/trac/php-intl/wiki/ErrorHandling). Digging through many zend internals, I wonder if there is a possibility to use a common ancestor class without cluttering namespaces in php. Something like class CommonErrorThings; class ResourceBundle extends CommonErrorThings; class Collator extends CommonErrorThings; in which CommonErrorThings is invisible to PHP and ResourceBundle/Collator offered to the user. Any doc and/or example link would be greatly appreciated Happy Holidays HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] zend_parse_method_parameters_ex: don't ignore flags
Hi!
As of now, zend_parse_method_parameters_ex does ignore the ex-flags if
called in a procedural context.
NB: Calling it in a procedural context is explicitely handled in the
code! It's not a false use of the function.
I suppose, the body was copied from zend_parse_method_parameters and the
"flags" correction got lost in one case.
HP
diff -r 8d27b606e890 Zend/zend_API.c
--- a/Zend/zend_API.c Wed Dec 23 10:40:28 2009 +0100
+++ b/Zend/zend_API.c Wed Dec 23 13:00:50 2009 +0100
@@ -923,7 +923,7 @@
RETURN_IF_ZERO_ARGS(num_args, p, quiet);
va_start(va, type_spec);
- retval = zend_parse_va_args(num_args, type_spec, &va, 0 TSRMLS_CC);
+ retval = zend_parse_va_args(num_args, type_spec, &va, flags TSRMLS_CC);
va_end(va);
} else {
p++;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [patch] PDO_FETCH_KEYS
Hi! Wez Furlong wrote: > What purpose does this serve exactly? PDO::FETCH_KEYS is supposed to be a "generalized" form of the existing PDO::FETCH_KEY_PAIR. The latter is limited to two column results and organises it into key=>value. PDO::FETCH_2D is an IMHO better strategy than the existing ATTR_FETCH_TABLE_NAMES. The latter includes two "information tokens" into one datum (the array index). > Why do we need to allocate an empty string for every database connection? The empty string is the default value for the attribute. NULL actually has a different meaning. Of course, the actual implementation of a default value is open for change, of course. > Why do we need this in the core? > There's a lot of manipulation being done here that is better suited to > happen in PHP script land where it's safer and easier to maintain. PDO::FETCH_2D is *NOT* easily implemented in PHP as it needs information unavailable before. PDO::FETCH_KEYS is just a generalization of the existing PDO::FETCH_KEY_PAIR. What do you mean by "manipulation"? I only intended to implement fetch modes I need. HPO PS: Please notice the updated patch. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PDO::FETCH_KEYS
Hoi!
Marcus Boerger wrote:
> can you add tests so we get a better idea?
> cvs add ; cvd di -N > patchfile.txt
I could... If I had a cvs account.
As I don't, please find attached an updated patch (I hope I got the zval
allocation right) as well as:
- pdo_034.phpt (updated in patch)
- pdo_035.phpt (addition, not in patch)
Please be aware that pdo_035.phpt may only pass on firebird and mysql as
it depends on an updated column information struct.
HPO
Index: ext/pdo/pdo_dbh.c
===
RCS file: /repository/php-src/ext/pdo/pdo_dbh.c,v
retrieving revision 1.82.2.31.2.17.2.2
diff -u -r1.82.2.31.2.17.2.2 pdo_dbh.c
--- ext/pdo/pdo_dbh.c 7 Oct 2007 05:22:05 - 1.82.2.31.2.17.2.2
+++ ext/pdo/pdo_dbh.c 27 Nov 2007 18:27:09 -
@@ -784,6 +784,15 @@
return SUCCESS;
}
+ case PDO_ATTR_2D_NULLBASE:
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
+ dbh->nullbase = (value ? estrdup( Z_STRVAL_P(value) ) :
NULL );
+
+ return SUCCESS;
+
default:
;
}
@@ -872,6 +881,8 @@
case PDO_ATTR_DEFAULT_FETCH_MODE:
RETURN_LONG(dbh->default_fetch_type);
+ case PDO_ATTR_2D_NULLBASE:
+ RETURN_STRING(dbh->nullbase, 1);
}
if (!dbh->methods->get_attribute) {
@@ -1331,10 +1342,11 @@
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_FETCH_POST",
(long)PDO_PARAM_EVT_FETCH_POST);
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_NORMALIZE",
(long)PDO_PARAM_EVT_NORMALIZE);
- REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_ASSOC",(long)PDO_FETCH_ASSOC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_NUM", (long)PDO_FETCH_NUM);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOTH", (long)PDO_FETCH_BOTH);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_2D", (long)PDO_FETCH_2D);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_OBJ", (long)PDO_FETCH_OBJ);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOUND",(long)PDO_FETCH_BOUND);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_COLUMN",(long)PDO_FETCH_COLUMN);
@@ -1343,7 +1355,8 @@
REGISTER_PDO_CLASS_CONST_LONG("FETCH_FUNC", (long)PDO_FETCH_FUNC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_GROUP",(long)PDO_FETCH_GROUP);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_UNIQUE",(long)PDO_FETCH_UNIQUE);
-
REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEY_PAIR);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEYS);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEYS",(long)PDO_FETCH_KEYS);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_CLASSTYPE",(long)PDO_FETCH_CLASSTYPE);
#if PHP_MAJOR_VERSION > 5 || PHP_MINOR_VERSION >= 1
REGISTER_PDO_CLASS_CONST_LONG("FETCH_SERIALIZE",(long)PDO_FETCH_SERIALIZE);
@@ -1372,7 +1385,7 @@
REGISTER_PDO_CLASS_CONST_LONG("ATTR_MAX_COLUMN_LEN",(long)PDO_ATTR_MAX_COLUMN_LEN);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_EMULATE_PREPARES",(long)PDO_ATTR_EMULATE_PREPARES);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_DEFAULT_FETCH_MODE",(long)PDO_ATTR_DEFAULT_FETCH_MODE);
-
+ REGISTER_PDO_CLASS_CONST_LONG("ATTR_2D_NULLBASE",
(long)PDO_ATTR_2D_NULLBASE);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_SILENT",
(long)PDO_ERRMODE_SILENT);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_WARNING",
(long)PDO_ERRMODE_WARNING);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_EXCEPTION",
(long)PDO_ERRMODE_EXCEPTION);
@@ -1472,13 +1485,17 @@
dbh->methods->rollback(dbh TSRMLS_CC);
dbh->in_txn = 0;
}
-
+
if (dbh->properties) {
zend_hash_destroy(dbh->properties);
efree(dbh->properties);
dbh->properties = NULL;
}
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
if (!dbh->is_persistent) {
dbh_free(dbh TSRMLS_CC);
} else if (dbh->methods && dbh->methods->persistent_shutdown) {
@@ -1496,6 +1513,7 @@
memset(dbh, 0, sizeof(*dbh));
dbh->ce = ce;
dbh->refcount = 1;
+ dbh->nullbase = estrdup( "" );
ALLOC_HASHTABLE(dbh->properties);
zend_hash_init(dbh->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
zend_hash_copy(dbh->properties, &ce->default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
Index: ext/pdo/pdo_stmt.c
===
RCS file: /repository/php-src/ext/pdo/pdo_stmt.c,v
retrieving revision 1.118.2.38.2.24.2.7
diff -u -r1.1
[PHP-DEV] [PATCH] PDO::FETCH_KEYS
Hi!
I "enhanced" my previous patch with the possibility of zero key rows...
HPO
Index: ext/pdo/pdo_dbh.c
===
RCS file: /repository/php-src/ext/pdo/pdo_dbh.c,v
retrieving revision 1.82.2.31.2.17.2.2
diff -u -r1.82.2.31.2.17.2.2 pdo_dbh.c
--- ext/pdo/pdo_dbh.c 7 Oct 2007 05:22:05 - 1.82.2.31.2.17.2.2
+++ ext/pdo/pdo_dbh.c 26 Nov 2007 16:38:16 -
@@ -784,6 +784,15 @@
return SUCCESS;
}
+ case PDO_ATTR_2D_NULLBASE:
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
+ dbh->nullbase = (value ? estrdup( Z_STRVAL_P(value) ) :
NULL );
+
+ return SUCCESS;
+
default:
;
}
@@ -872,6 +881,8 @@
case PDO_ATTR_DEFAULT_FETCH_MODE:
RETURN_LONG(dbh->default_fetch_type);
+ case PDO_ATTR_2D_NULLBASE:
+ RETURN_STRING(dbh->nullbase, 1);
}
if (!dbh->methods->get_attribute) {
@@ -1331,10 +1342,11 @@
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_FETCH_POST",
(long)PDO_PARAM_EVT_FETCH_POST);
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_NORMALIZE",
(long)PDO_PARAM_EVT_NORMALIZE);
- REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_ASSOC",(long)PDO_FETCH_ASSOC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_NUM", (long)PDO_FETCH_NUM);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOTH", (long)PDO_FETCH_BOTH);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_2D", (long)PDO_FETCH_2D);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_OBJ", (long)PDO_FETCH_OBJ);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOUND",(long)PDO_FETCH_BOUND);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_COLUMN",(long)PDO_FETCH_COLUMN);
@@ -1343,7 +1355,8 @@
REGISTER_PDO_CLASS_CONST_LONG("FETCH_FUNC", (long)PDO_FETCH_FUNC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_GROUP",(long)PDO_FETCH_GROUP);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_UNIQUE",(long)PDO_FETCH_UNIQUE);
-
REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEY_PAIR);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEYS);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEYS",(long)PDO_FETCH_KEYS);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_CLASSTYPE",(long)PDO_FETCH_CLASSTYPE);
#if PHP_MAJOR_VERSION > 5 || PHP_MINOR_VERSION >= 1
REGISTER_PDO_CLASS_CONST_LONG("FETCH_SERIALIZE",(long)PDO_FETCH_SERIALIZE);
@@ -1372,7 +1385,7 @@
REGISTER_PDO_CLASS_CONST_LONG("ATTR_MAX_COLUMN_LEN",(long)PDO_ATTR_MAX_COLUMN_LEN);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_EMULATE_PREPARES",(long)PDO_ATTR_EMULATE_PREPARES);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_DEFAULT_FETCH_MODE",(long)PDO_ATTR_DEFAULT_FETCH_MODE);
-
+ REGISTER_PDO_CLASS_CONST_LONG("ATTR_2D_NULLBASE",
(long)PDO_ATTR_2D_NULLBASE);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_SILENT",
(long)PDO_ERRMODE_SILENT);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_WARNING",
(long)PDO_ERRMODE_WARNING);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_EXCEPTION",
(long)PDO_ERRMODE_EXCEPTION);
@@ -1472,13 +1485,17 @@
dbh->methods->rollback(dbh TSRMLS_CC);
dbh->in_txn = 0;
}
-
+
if (dbh->properties) {
zend_hash_destroy(dbh->properties);
efree(dbh->properties);
dbh->properties = NULL;
}
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
if (!dbh->is_persistent) {
dbh_free(dbh TSRMLS_CC);
} else if (dbh->methods && dbh->methods->persistent_shutdown) {
@@ -1496,6 +1513,7 @@
memset(dbh, 0, sizeof(*dbh));
dbh->ce = ce;
dbh->refcount = 1;
+ dbh->nullbase = estrdup( "" );
ALLOC_HASHTABLE(dbh->properties);
zend_hash_init(dbh->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
zend_hash_copy(dbh->properties, &ce->default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
Index: ext/pdo/pdo_stmt.c
===
RCS file: /repository/php-src/ext/pdo/pdo_stmt.c,v
retrieving revision 1.118.2.38.2.24.2.7
diff -u -r1.118.2.38.2.24.2.7 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 20 Nov 2007 23:12:17 - 1.118.2.38.2.24.2.7
+++ ext/pdo/pdo_stmt.c 26 Nov 2007 16:38:16 -
@@ -886,6 +886,68 @@
}
/* }}} */
+/* iteratively create array out of a column */
+static void do_fetch_keys_iterative( pdo_stmt_t *stmt, zval *base, zval *index
) {
+ zval *val;
+ zval **valp;
+ int isf
[PHP-DEV] [patch] PDO_FETCH_KEYS
Hi!
I discovered that PDO::FETCH_KEY_PAIR does not work as documented.
Documented is:
'Fetch into an array where the 1st column is a key and all subsequent
columns are values'
Actually, all but two column result sets throw an error...
Then I thought about generalizing the fetch mode. Have 1..n 'key'
columns. If only one value is left, assign it as a scalar. If multiple
columns are left over, have it taken as FETCH_ASSOC.
Please find attached a humble suggestion to generalize FETCH_KEY_PAIR to
FETCH_KEYS, including an attribute to define the number of 'key' columns
(defaults to one).
The result should be fully backwards compatible.
Please give me your suggestions.
HPO
PS: My diff includes my 'old' FETCH_2D patch.
diff -u -r1.82.2.31.2.17.2.2 pdo_dbh.c
--- ext/pdo/pdo_dbh.c 7 Oct 2007 05:22:05 - 1.82.2.31.2.17.2.2
+++ ext/pdo/pdo_dbh.c 24 Nov 2007 21:19:47 -
@@ -784,6 +784,15 @@
return SUCCESS;
}
+ case PDO_ATTR_2D_NULLBASE:
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
+ dbh->nullbase = (value ? estrdup( Z_STRVAL_P(value) ) :
NULL );
+
+ return SUCCESS;
+
default:
;
}
@@ -872,6 +881,8 @@
case PDO_ATTR_DEFAULT_FETCH_MODE:
RETURN_LONG(dbh->default_fetch_type);
+ case PDO_ATTR_2D_NULLBASE:
+ RETURN_STRING(dbh->nullbase, 1);
}
if (!dbh->methods->get_attribute) {
@@ -1331,10 +1342,11 @@
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_FETCH_POST",
(long)PDO_PARAM_EVT_FETCH_POST);
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_NORMALIZE",
(long)PDO_PARAM_EVT_NORMALIZE);
- REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_ASSOC",(long)PDO_FETCH_ASSOC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_NUM", (long)PDO_FETCH_NUM);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOTH", (long)PDO_FETCH_BOTH);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_2D", (long)PDO_FETCH_2D);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_OBJ", (long)PDO_FETCH_OBJ);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOUND",(long)PDO_FETCH_BOUND);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_COLUMN",(long)PDO_FETCH_COLUMN);
@@ -1343,7 +1355,8 @@
REGISTER_PDO_CLASS_CONST_LONG("FETCH_FUNC", (long)PDO_FETCH_FUNC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_GROUP",(long)PDO_FETCH_GROUP);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_UNIQUE",(long)PDO_FETCH_UNIQUE);
-
REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEY_PAIR);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEY_PAIR",(long)PDO_FETCH_KEYS);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_KEYS",(long)PDO_FETCH_KEYS);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_CLASSTYPE",(long)PDO_FETCH_CLASSTYPE);
#if PHP_MAJOR_VERSION > 5 || PHP_MINOR_VERSION >= 1
REGISTER_PDO_CLASS_CONST_LONG("FETCH_SERIALIZE",(long)PDO_FETCH_SERIALIZE);
@@ -1372,7 +1385,7 @@
REGISTER_PDO_CLASS_CONST_LONG("ATTR_MAX_COLUMN_LEN",(long)PDO_ATTR_MAX_COLUMN_LEN);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_EMULATE_PREPARES",(long)PDO_ATTR_EMULATE_PREPARES);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_DEFAULT_FETCH_MODE",(long)PDO_ATTR_DEFAULT_FETCH_MODE);
-
+ REGISTER_PDO_CLASS_CONST_LONG("ATTR_2D_NULLBASE",
(long)PDO_ATTR_2D_NULLBASE);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_SILENT",
(long)PDO_ERRMODE_SILENT);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_WARNING",
(long)PDO_ERRMODE_WARNING);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_EXCEPTION",
(long)PDO_ERRMODE_EXCEPTION);
@@ -1472,13 +1485,17 @@
dbh->methods->rollback(dbh TSRMLS_CC);
dbh->in_txn = 0;
}
-
+
if (dbh->properties) {
zend_hash_destroy(dbh->properties);
efree(dbh->properties);
dbh->properties = NULL;
}
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
if (!dbh->is_persistent) {
dbh_free(dbh TSRMLS_CC);
} else if (dbh->methods && dbh->methods->persistent_shutdown) {
@@ -1496,6 +1513,7 @@
memset(dbh, 0, sizeof(*dbh));
dbh->ce = ce;
dbh->refcount = 1;
+ dbh->nullbase = estrdup( "" );
ALLOC_HASHTABLE(dbh->properties);
zend_hash_init(dbh->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
zend_hash_copy(dbh->properties, &ce->default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
diff -u -r1.118.2.38.2.24.2.7 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 20 Nov 2007 23:12:17 - 1.118.2.38.2.24
Re: [PHP-DEV] [PATCH] PDO::FETCH_2D
Hi!
Lukas Kahwe Smith wrote:
> defaults. In this case I would suggest making the empty string the default.
I attach a cleaned patch - with empty string as a default 'null base'.
(patch against todays cvs)
HPO
diff -u -r1.82.2.31.2.17.2.2 pdo_dbh.c
--- ext/pdo/pdo_dbh.c 7 Oct 2007 05:22:05 - 1.82.2.31.2.17.2.2
+++ ext/pdo/pdo_dbh.c 20 Nov 2007 14:23:14 -
@@ -784,6 +784,15 @@
return SUCCESS;
}
+ case PDO_ATTR_2D_NULLBASE:
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
+ dbh->nullbase = (value ? estrdup( Z_STRVAL_P(value) ) :
NULL );
+
+ return SUCCESS;
+
default:
;
}
@@ -872,6 +881,8 @@
case PDO_ATTR_DEFAULT_FETCH_MODE:
RETURN_LONG(dbh->default_fetch_type);
+ case PDO_ATTR_2D_NULLBASE:
+ RETURN_STRING(dbh->nullbase, 1);
}
if (!dbh->methods->get_attribute) {
@@ -1331,10 +1342,11 @@
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_FETCH_POST",
(long)PDO_PARAM_EVT_FETCH_POST);
REGISTER_PDO_CLASS_CONST_LONG("PARAM_EVT_NORMALIZE",
(long)PDO_PARAM_EVT_NORMALIZE);
- REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_ASSOC",(long)PDO_FETCH_ASSOC);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_NUM", (long)PDO_FETCH_NUM);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOTH", (long)PDO_FETCH_BOTH);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_2D", (long)PDO_FETCH_2D);
+ REGISTER_PDO_CLASS_CONST_LONG("FETCH_LAZY", (long)PDO_FETCH_LAZY);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_OBJ", (long)PDO_FETCH_OBJ);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_BOUND",(long)PDO_FETCH_BOUND);
REGISTER_PDO_CLASS_CONST_LONG("FETCH_COLUMN",(long)PDO_FETCH_COLUMN);
@@ -1372,7 +1384,7 @@
REGISTER_PDO_CLASS_CONST_LONG("ATTR_MAX_COLUMN_LEN",(long)PDO_ATTR_MAX_COLUMN_LEN);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_EMULATE_PREPARES",(long)PDO_ATTR_EMULATE_PREPARES);
REGISTER_PDO_CLASS_CONST_LONG("ATTR_DEFAULT_FETCH_MODE",(long)PDO_ATTR_DEFAULT_FETCH_MODE);
-
+ REGISTER_PDO_CLASS_CONST_LONG("ATTR_2D_NULLBASE",
(long)PDO_ATTR_2D_NULLBASE);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_SILENT",
(long)PDO_ERRMODE_SILENT);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_WARNING",
(long)PDO_ERRMODE_WARNING);
REGISTER_PDO_CLASS_CONST_LONG("ERRMODE_EXCEPTION",
(long)PDO_ERRMODE_EXCEPTION);
@@ -1472,13 +1484,17 @@
dbh->methods->rollback(dbh TSRMLS_CC);
dbh->in_txn = 0;
}
-
+
if (dbh->properties) {
zend_hash_destroy(dbh->properties);
efree(dbh->properties);
dbh->properties = NULL;
}
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+
if (!dbh->is_persistent) {
dbh_free(dbh TSRMLS_CC);
} else if (dbh->methods && dbh->methods->persistent_shutdown) {
@@ -1496,6 +1512,7 @@
memset(dbh, 0, sizeof(*dbh));
dbh->ce = ce;
dbh->refcount = 1;
+ dbh->nullbase = estrdup( "" );
ALLOC_HASHTABLE(dbh->properties);
zend_hash_init(dbh->properties, 0, NULL, ZVAL_PTR_DTOR, 0);
zend_hash_copy(dbh->properties, &ce->default_properties,
(copy_ctor_func_t) zval_add_ref, (void *) &tmp, sizeof(zval *));
diff -u -r1.118.2.38.2.24.2.5 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 31 Oct 2007 12:57:51 - 1.118.2.38.2.24.2.5
+++ ext/pdo/pdo_stmt.c 20 Nov 2007 14:23:15 -
@@ -894,7 +894,8 @@
int flags = how & PDO_FETCH_FLAGS, idx, old_arg_count = 0;
zend_class_entry *ce = NULL, *old_ce = NULL;
zval grp_val, *grp, **pgrp, *retval, *old_ctor_args = NULL;
-
+ zval *nullbase = NULL;
+
if (how == PDO_FETCH_USE_DEFAULT) {
how = stmt->default_fetch_type;
}
@@ -925,6 +926,10 @@
case PDO_FETCH_BOTH:
case PDO_FETCH_NUM:
case PDO_FETCH_NAMED:
+ case PDO_FETCH_2D:
+ case PDO_FETCH_2D_NUM:
+ case PDO_FETCH_2D_ASSOC:
+ case PDO_FETCH_2D_BOTH:
if (!return_all) {
ALLOC_HASHTABLE(return_value->value.ht);
zend_hash_init(return_value->value.ht,
stmt->column_count, NULL, ZVAL_PTR_DTOR, 0);
@@ -1060,10 +1065,59 @@
for (idx = 0; i < stmt->column_count; i++, idx++) {
zval *val;
+ zval *base2d;
MAKE_STD_ZVAL(val);
Re: [PHP-DEV] [PATCH] PDO::FETCH_2D
Hi! Thanks for your response! Lukas Kahwe Smith wrote: >> Not sure how real world useful this is. What I have seen more is a I often run into a situation like the following: We need a "framework like" class to change *joined* tables. The framework itself has no inherent knowledge about table fields, but (anyhow) loads table definitions. This functionality is useful for: a) duplicate field names in different tables (FETCH_NAMED does not help) b) update tables, as - without any additional work - I have the fields "by table" Access to fields w/o knowing their table is possible by combining FETCH_2D with FETCH_ASSOC or FETCH_NUM. As that creates references, changes to "table-less" fields are represented in the "table" fields automagically ;) I don't know how often, but in "my" real world, that's bloody useful. But at least much more useful than the existing ATTR.FETCH_TABLE_NAMES... As for "empty string" index: In my proposal, you could: setAttribute( PDO::ATTR_2D_NULLBASE, '') Would your really like to *fix* it to that? > like I said ideally PDO would know about FKs and use those to build the > tree structure automagically. Any added *functionality* (defined by: PDO *knows*) must be sincerely discussed, I think. My proposal only adds a way to return fetched data - PDO does not *know* anything more. > I would like to see: > 1) lazy connect > 2) driver independent DSN support Please bear with me - I'm not a practiced coder. I'm sure my humble proposal contains many bugs... But why lazy connects? As for DSN: Has anybody discussed including username/password into the DSN? mysql:username:[EMAIL PROTECTED] HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] PDO::FETCH_2D
Hi!
As per my rfd from 2007-11-14, I prepared a FETCH_2D (work title) patch
- where a row result consists of a two-dimensional hash, the first
dimension being the table name, the second the field name.
Summary:
I propose to rearrange FETCH mode constants, such that FETCH_NUM,
FETCH_ASSOC and (new) FETCH_2D are bitwise combineable:
FETCH_ASSOC | FETCH_NUM = FETCH_BOTH
FETCH_2D | FETCH_NUM = FETCH_2D_NUM
FETCH_2D is the "core" of my proposal. It's like the
ATTR_FETCH_TABLE_NAMES, enhanced in arrays. Columns are to be found on
the second level:
$result[tablename][columname]
Columns that don't result from a table are added to a "null base" (work
title). The default "null base" is the first level array:
$result[computedcolumn]
The connection attribute ATTR_2D_NULLBASE (work title) defines an
alternative "null base":
$result[nullbase][computedcolumn]
FETCH_2D should be combineable with FETCH_ASSOC and/or FETCH_NUM. The
corresponding entries are added to the "null base" (a reference).
Status:
The attached patch against CVS PHP_5_3 supports the described
functionality with pdo_mysql and pdo_firebird (my primary).
Please let me know if I'm on a totally wrong path.
HPO
diff -u -r1.18.2.1.2.5.2.7 firebird_statement.c
--- ext/pdo_firebird/firebird_statement.c 16 Nov 2007 12:27:49 -
1.18.2.1.2.5.2.7
+++ ext/pdo_firebird/firebird_statement.c 19 Nov 2007 19:46:52 -
@@ -99,10 +99,7 @@
S->cursor_open = 0;
/* assume all params have been bound */
- if ((S->statement_type == isc_info_sql_stmt_exec_procedure &&
- isc_dsql_execute2(H->isc_status, &H->tr,
&S->stmt, PDO_FB_SQLDA_VERSION,
- S->in_sqlda, &S->out_sqlda))
- || isc_dsql_execute(H->isc_status, &H->tr,
&S->stmt, PDO_FB_SQLDA_VERSION,
+ if (isc_dsql_execute(H->isc_status, &H->tr, &S->stmt,
PDO_FB_SQLDA_VERSION,
S->in_sqlda)) {
break;
}
@@ -113,8 +110,8 @@
}
*S->name = 0;
- S->cursor_open = 1;
- S->exhausted = 0;
+ S->cursor_open = (S->out_sqlda.sqln > 0);
+ S->exhausted = !S->cursor_open;
return 1;
} while (0);
@@ -136,19 +133,15 @@
strcpy(stmt->error_code, "HY000");
H->last_app_error = "Cannot fetch from a closed cursor";
} else if (!S->exhausted) {
-
- /* an EXECUTE PROCEDURE statement can be fetched from once,
without calling the API, because
-* the result was returned in the execute call */
+ if (isc_dsql_fetch(H->isc_status, &S->stmt,
PDO_FB_SQLDA_VERSION, &S->out_sqlda)) {
+ if (H->isc_status[0] && H->isc_status[1]) {
+ RECORD_ERROR(stmt);
+ }
+ S->exhausted = 1;
+ return 0;
+ }
if (S->statement_type == isc_info_sql_stmt_exec_procedure) {
S->exhausted = 1;
- } else {
- if (isc_dsql_fetch(H->isc_status, &S->stmt,
PDO_FB_SQLDA_VERSION, &S->out_sqlda)) {
- if (H->isc_status[0] && H->isc_status[1]) {
- RECORD_ERROR(stmt);
- }
- S->exhausted = 1;
- return 0;
- }
}
return 1;
}
@@ -172,8 +165,10 @@
colname_len = (S->H->fetch_table_names && var->relname_length)
? (var->aliasname_length +
var->relname_length + 1)
: (var->aliasname_length);
- col->precision = -var->sqlscale;
+ col->precision = -var->sqlscale;
col->maxlen = var->sqllen;
+ col->relname = (var->relname_length ? estrndup(var->relname,
var->relname_length) : NULL);
+ col->relnamelen = var->relname_length;
col->namelen = colname_len;
col->name = cp = emalloc(colname_len + 1);
if (colname_len > var->aliasname_length) {
diff -u -r1.82.2.31.2.17.2.2 pdo_dbh.c
--- ext/pdo/pdo_dbh.c 7 Oct 2007 05:22:05 - 1.82.2.31.2.17.2.2
+++ ext/pdo/pdo_dbh.c 19 Nov 2007 19:46:54 -
@@ -784,6 +784,13 @@
return SUCCESS;
}
+ case PDO_ATTR_2D_NULLBASE:
+ if( dbh->nullbase ) {
+ efree( dbh->nullbase );
+ }
+ dbh->nullbase = estrndup(Z_STRVAL_P(value),
Z_STRLEN_P(value));
+ return SUCCESS;
+
default:
;
}
@@ -872,6
[PHP-DEV] Re: Question about superglobals
Hi! Sam Barrow wrote: > I am trying to develop a patch for personal use to enable custom > superglobals. I may have missed your point. But does the pecl extension "runkit" not fulfill your desires? HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFD: PDO::FETCH_2D or a hierarchical FETCH_ASSOC
Hi! I'm surely not the only one that ran into the problem of queries returning several columns with identical names. I didn't find anything about my following suggestion in the archives - if however, I'm only warming up old cheese, please ignore/bash me ;) As I see, there is an connection attribute ATTR_FETCH_TABLE_NAMES that - depending on driver support - qualifies column names: column 'a' on table 'b' => $result['b.a'] Given support for that attribute, a FETCH_ASSOC returns a one-dimensional array with qualified column names. However, I don't consider this solution as good as it could be... E.g. it's rather hard to extract the values from a specific table (short of running over the whole index array). There is useful information "hidden" in the text... I therefore suggest a fetch mode that returns TWO-DIMENSIONAL arrays, the first dimension being the table/relation name, the second the column identification: column 'a' on table 'b' => $result['b']['a'] Such a solution would ease a lot of my 'framework' tasks. Open questions/ideas: - columns not originating from a table? Those could be entered in the first hierarchy (possibility of conflict with table names): $result['computed_value'] or in sort of a 'pseudo table' like '0' or 'unknown' (possibility of conflict by that pseudo name): $result['unknown']['computed_value'] - separate fetch mode or mode modification flag? There could be uses for a modified FETCH_BOTH as well, with column numbers all on first level plus hierarchical FETCH_2D. - what about a hybrid fetch? There could be uses for sort of a hybrid fetch, which would result in FETCH_ASSOC (each column name only once, first level) plus FETCH_2D (all columns hierarchically). To reduce memory consumption, the "doubly represented" columns could share a Z_VAL reference. Compatibility issues: - A quick glance only reveals fetchColumn and getColumnMeta as obvious compatibility issues. Should they be enhanced to not only accept column numbers, but textual column identifiers as well... - A hybrid mode (see above) that works 1:1 with existing code plus offers the advantages of hierarchical access would only be feasible with 'hidden' keys. I don't think that's necessary. What do you think? HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pdo_firebird: PDO::ATTR_FETCH_TABLE_NAMES support
Hi1 Lukas Kahwe Smith wrote: > Driver specific attributes and methods should be prefixed accordingly. > What does this option do btw? Is this about qualifying column names > with the table name? In that case this is something that should maybe > be a standard attribute, since its also supported by sqlite and maybe > some other RDBMS. It's a documented attribute in the manual (list of constants) - sorry if I should have misunderstood that. HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pdo_firebird: "RETURNING" queries/closeCursor (#43246/43271)
Hi! Marcus Boerger wrote: > account name, '#if ACCOUNT_0' but oh wait you have none. ;) > Both these patches > as well as thew table stuff patch look fine. Care to get a cvs account for > pdo_firebird? > If it is that easy to get one: yes please. But before I enter (possible) pdo_firebird politics, could you tell me if there is currently an active maintainer? Thanks HPO -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pdo_firebird: PDO::ATTR_FETCH_TABLE_NAMES support
Hi!
I just needed ATTR_FETCH_TABLE_NAMES support in pdo_firebird. W/o any
knowledge about PHP politics, please let me humbly offer the
corresponding patch.
For any suggestions, please don't hesitate to contact me.
Greets
HPO
--- php5-orig/ext/pdo_firebird/firebird_driver.c2007-11-12
16:59:34.0 +0100
+++ php5/ext/pdo_firebird/firebird_driver.c 2007-11-14 15:42:18.0
+0100
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: firebird_driver.c,v 1.23 2007/10/30 18:06:02 lwe Exp $ */
+/* $Id: firebird_driver.c,v 1.17.2.2.2.4.2.1 2007/10/30 16:30:40 lwe Exp $ */
#ifdef HAVE_CONFIG_H
#include "config.h"
@@ -493,6 +493,11 @@
}
return 1;
+ case PDO_ATTR_FETCH_TABLE_NAMES:
+ convert_to_boolean(val);
+ H->column_name_format = Z_BVAL_P(val);
+ return 1;
+
case PDO_FB_ATTR_DATE_FORMAT:
convert_to_string(val);
if (H->date_format) {
@@ -668,7 +673,7 @@
dbh->methods = &firebird_methods;
dbh->native_case = PDO_CASE_UPPER;
dbh->alloc_own_columns = 1;
-
+
ret = 1;
} while (0);
diff -ru php5-orig/ext/pdo_firebird/firebird_statement.c
php5/ext/pdo_firebird/firebird_statement.c
--- php5-orig/ext/pdo_firebird/firebird_statement.c 2007-11-12
21:54:13.0 +0100
+++ php5/ext/pdo_firebird/firebird_statement.c 2007-11-14 15:45:58.0
+0100
@@ -169,15 +169,28 @@
pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt->driver_data;
struct pdo_column_data *col = &stmt->columns[colno];
XSQLVAR *var = &S->out_sqlda.sqlvar[colno];
-
+ int colname_size;
+ char *colname_runner;
+
/* allocate storage for the column */
var->sqlind = (void*)emalloc(var->sqllen + 2*sizeof(short));
var->sqldata = &((char*)var->sqlind)[sizeof(short)];
+ colname_size = (var->relname_length && S->H->column_name_format)
+ ? (var->aliasname_length + var->relname_length + 1)
+ : (var->aliasname_length);
col->precision = -var->sqlscale;
col->maxlen = var->sqllen;
- col->namelen = var->aliasname_length;
- col->name = estrndup(var->aliasname,var->aliasname_length);
+ col->namelen = colname_size;
+ col->name = colname_runner = emalloc( colname_size+1 );
+ if( colname_size > var->aliasname_length ) {
+ memmove( colname_runner, var->relname, var->relname_length );
+ colname_runner += var->relname_length;
+ *colname_runner++ = '.';
+ }
+ memmove( colname_runner, var->aliasname, var->aliasname_length );
+ colname_runner += var->aliasname_length;
+ *colname_runner = 0;
col->param_type = PDO_PARAM_STR;
return 1;
diff -ru php5-orig/ext/pdo_firebird/php_pdo_firebird_int.h
php5/ext/pdo_firebird/php_pdo_firebird_int.h
--- php5-orig/ext/pdo_firebird/php_pdo_firebird_int.h 2007-11-12
16:59:35.0 +0100
+++ php5/ext/pdo_firebird/php_pdo_firebird_int.h2007-11-14
13:44:28.0 +0100
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: php_pdo_firebird_int.h,v 1.13 2007/10/30 18:02:45 lwe Exp $ */
+/* $Id: php_pdo_firebird_int.h,v 1.10.2.1.2.1.2.1 2007/10/30 16:26:25 lwe Exp
$ */
#ifndef PHP_PDO_FIREBIRD_INT_H
#define PHP_PDO_FIREBIRD_INT_H
@@ -81,7 +81,7 @@
char *date_format;
char *time_format;
char *timestamp_format;
-
+ int column_name_format;
} pdo_firebird_db_handle;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] pdo_firebird: "RETURNING" queries/closeCursor (#43246/43271)
Hi!
According to the archive, this might be the list for concrete diffs - if
not, please excuse me.
I tried pdo_firebird (CVS PHP_5_3) and quickly ran across to bugs:
a) RETURNING queries fail
pdo_firebird - against the published docs - wants to return stored
procedure return values by the "execute" call. As it is, RETURNING
queries (for the lower level library) go in the same bucket; big nono.
My proposed change removes "special" handling of stored procedure calls
alltogether - as it seems not only undocumented, but against the docs.
As a "side effect", RETURNING queries work again.
b) PDOStatement->closeCursor not implemented
Whenever I tried to re-use a prepared statement, I got an error msg
about reusing an open cursor. As it seems, mere cursor closing is not
currently implemented (discarding the statement closes the cursor).
My proposed change adds a minimal "cursor_closer".
Please excuse form and/or function of my diffs (or human language
mistake). I'm neither a C nor a PHP guru. Nevertheless I humbly present
those for your consideration.
HPO
diff -u php5-orig/ext/pdo_firebird/firebird_statement.c
php5/ext/pdo_firebird/firebird_statement.c
--- php5-orig/ext/pdo_firebird/firebird_statement.c 2007-11-12
16:59:34.0 +0100
+++ php5/ext/pdo_firebird/firebird_statement.c 2007-11-12 16:58:46.0
+0100
@@ -99,11 +99,15 @@
/* assume all params have been bound */
+#if 0
if ((S->statement_type == isc_info_sql_stmt_exec_procedure &&
isc_dsql_execute2(H->isc_status, &H->tr,
&S->stmt, PDO_FB_SQLDA_VERSION,
S->in_sqlda, &S->out_sqlda))
|| isc_dsql_execute(H->isc_status, &H->tr,
&S->stmt, PDO_FB_SQLDA_VERSION,
S->in_sqlda)) {
+#else
+ if (isc_dsql_execute(H->isc_status, &H->tr, &S->stmt,
PDO_FB_SQLDA_VERSION, S->in_sqlda)) {
+#endif
break;
}
@@ -138,9 +142,11 @@
/* an EXECUTE PROCEDURE statement can be fetched from once,
without calling the API, because
* the result was returned in the execute call */
+#if 0
if (S->statement_type == isc_info_sql_stmt_exec_procedure) {
S->exhausted = 1;
} else {
+#endif
if (isc_dsql_fetch(H->isc_status, &S->stmt,
PDO_FB_SQLDA_VERSION, &S->out_sqlda)) {
if (H->isc_status[0] && H->isc_status[1]) {
RECORD_ERROR(stmt);
@@ -148,7 +154,9 @@
S->exhausted = 1;
return 0;
}
+#if 0
}
+#endif
return 1;
}
return 0;
--- php5-orig/ext/pdo_firebird/firebird_statement.c 2007-11-12
21:54:13.0 +0100
+++ php5/ext/pdo_firebird/firebird_statement.c 2007-11-12 21:51:03.0
+0100
@@ -621,6 +620,22 @@
}
/* }}} */
+static int firebird_stmt_cursor_closer(pdo_stmt_t *stmt TSRMLS_DC) /* {{{ */
+{
+ pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt->driver_data;
+ int result = 1;
+
+ /* close the statement */
+ if (isc_dsql_free_statement(S->H->isc_status, &S->stmt, DSQL_close)) {
+ RECORD_ERROR(stmt);
+ result = 0;
+ }
+
+ return result;
+}
+/* }}} */
+
+
struct pdo_stmt_methods firebird_stmt_methods = { /* {{{ */
firebird_stmt_dtor,
firebird_stmt_execute,
@@ -629,7 +644,10 @@
firebird_stmt_get_col,
firebird_stmt_param_hook,
firebird_stmt_set_attribute,
- firebird_stmt_get_attribute
+ firebird_stmt_get_attribute,
+ NULL,
+ NULL,
+ firebird_stmt_cursor_closer
};
/* }}} */
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
