#44597 [NoF->Opn]: Postgres driver does not prepare booleans correctly
ID: 44597 User updated by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com -Status: No Feedback +Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: This is still reproducible on 5.3.0 paired with PG 8.x Previous Comments: [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: "" [2009-05-03 01:00:12] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-04-25 15:02:13] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ ---- [2009-02-04 03:57:28] kenaniah at gmail dot com This issue seems like it would be a very easy fix and can be reproduced without fail, regardless of server environment or PHP version. A fix would be greatly appreciated The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44597 -- Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#44597 [Opn]: Postgres driver does not prepare booleans correctly
ID: 44597 User updated by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: In response to sjoerd, this may very well be a product of bad documentation, but that does not exclude the functional use case. One could reasonably claim that proper detection of parameter types should in fact be part of the functional definition of execute(). Virtually every database interface built on top of PDO works around this boolean "bug" and allows support for mixed content in the parameter array to a prepared statement. IMHO, the PDO core should therefore be no different. Whether classified as a bug or a feature, I believe that this should still be addressed. Previous Comments: [2009-09-21 19:18:21] sjo...@php.net I think this is not a bug but a limitation of execute(): it assumes the values in the array are string. If you want it interpreted differently, you should call bindParam() with a data_type parameter. I filed Bug #49614 "PDOStatement::execute assumes string values in array" to clarify the documentation. [2009-09-13 20:55:01] kenaniah at gmail dot com This is still reproducible on 5.3.0 paired with PG 8.x [2009-09-13 19:08:46] ant at specialops dot ath dot cx I can still reproduce this on PHP 5.3.0 and PostgreSQL 8.4.1. [2009-06-14 11:53:21] execut3 at gmail dot com The issue is still not fixed, I'm with PHP 5.2.6 on Ubuntu and postgresql 8.3. ERROR: invalid input syntax for type boolean: "" [2009-05-03 01:00:12] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/44597 -- Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#44597 [Opn]: [PATCH] Postgres driver does not prepare booleans correctly
ID: 44597 User updated by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: In response to sjored, I believe there is huge disagreement over that issue, and I can personally speak for many of my colleagues in saying that. While I understand the repercussions of the patch, I would also like to point out that the example cited depends on buggy functionality in the first place. For that reason alone, I humbly submit that such a case should not be considered when weighing the implementation of the patch. On the second point, I believe we have another difference of opinion. All DBMSs perform their own casting on query parameters to match internal data types. For example, certain DBs honor the *string* 'False' as a boolean value, whereas a simple boolean cast performed in PHP would result in the said parameter evaluating to TRUE. In addition, other transformations may be applied to a passed parameter based on localization, custom data types, complex data types, etc. which vary from vendor to vendor and schema to schema. The role of PDO should be to transparently forward parameters to queries via their respective PHP and PDO-recognized data types. Now concerning the third point: PHP is a loosely-typed language. There is beauty in being able to provide mixed parameters to functions. There is nothing wrong with allowing a "mixed" parameter to be passed to a query either. Most DBs operate perfectly fine when receiving mixed parameters, and rightfully throw an error when something is amiss. Passing 'True', TRUE, or 1 to a boolean database field is perfectly acceptable in many systems. And concerning your last statement: PHP should never under any circumstance attempt to think for the programmer. I expect a database abstraction layer to pass parameters along transparently *because* it is an abstraction layer. A programming language is not smarter than the one who implements it, and it is impossible to mitigate an error in logic. Rather, it is better for an error to be returned in order so that the erroneous logic be corrected, as their may be an even greater issue at hand. In closing, I believe that the implementation of a patch for this issue would be more inline with the general philosophy and design patterns that govern PHP than the current functionality today, to the point that I maintain my position that the current functionality is in fact buggy. I merely ask that PDO -- true to the form and function of an abstraction layer -- would pass parameters along in their respective data types without casting them to "string" of all things. I thank everyone who has participated in this issue thus far (especially sjored for the patch submitted), and am looking forward to this issue being resolved in an upcoming release. Previous Comments: [2009-10-04 18:46:07] sjo...@php.net It is a bad idea to determine the PDO type from the PHP type. First, it would break existing scripts which assume false is cast to an empty string, like this: $a[] = strstr($foo, $bar); // may return false $pdo->execute($a); Secondly, the correct type to use is the type of the column, not the type of the PHP parameter. Consider the following query: SELECT * FROM foo WHERE a=? If a is a boolean, the parameter to execute() or bindBaram() should be converted to a boolean, no matter what the type of the passed parameter is. Finally, one of PHP features is that it dynamically changes types. The type of a variable should be transparent to the user. Therefore, the behavior of a function should not change when it is passed another type. To solve this, you should always specify the PDO type. Only the programmer knows which types the column in the query have, PHP can not determine this automatically. [2009-09-22 18:31:34] sjo...@php.net Currently, every variable is assumed to be PDO_PARAM_STR. This patch changes this to PDO_PARAM_INT or PDO_PARAM_BOOL if the passed variable is a long or a bool, respectively. http://www.gissen.nl/files/bug44597.patch This may break existing scripts, which depend on false being converted to an empty string. -------- [2009-09-21 19:48:55] kenaniah at gmail dot com In response to sjoerd, this may very well be a product of bad documentation, but that does not exclude the functional use case. One could reasonably claim that proper detection of parameter types should in fact be part of the functional definition of execute(). Virtually every database interface built on top of PDO works around this boolean "bug" and allows support for mixed content in the parameter array to a prepared
#44597 [Com]: [PATCH] Postgres driver does not prepare booleans correctly
ID: 44597 Comment by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com Status: Open Bug Type: PDO related Operating System: Red Hat 4.1.1 PHP Version: 5.2.6 New Comment: *Sjoerd My apologies on the incorrect spelling. Previous Comments: [2009-10-05 06:07:07] kenaniah at gmail dot com In response to sjored, I believe there is huge disagreement over that issue, and I can personally speak for many of my colleagues in saying that. While I understand the repercussions of the patch, I would also like to point out that the example cited depends on buggy functionality in the first place. For that reason alone, I humbly submit that such a case should not be considered when weighing the implementation of the patch. On the second point, I believe we have another difference of opinion. All DBMSs perform their own casting on query parameters to match internal data types. For example, certain DBs honor the *string* 'False' as a boolean value, whereas a simple boolean cast performed in PHP would result in the said parameter evaluating to TRUE. In addition, other transformations may be applied to a passed parameter based on localization, custom data types, complex data types, etc. which vary from vendor to vendor and schema to schema. The role of PDO should be to transparently forward parameters to queries via their respective PHP and PDO-recognized data types. Now concerning the third point: PHP is a loosely-typed language. There is beauty in being able to provide mixed parameters to functions. There is nothing wrong with allowing a "mixed" parameter to be passed to a query either. Most DBs operate perfectly fine when receiving mixed parameters, and rightfully throw an error when something is amiss. Passing 'True', TRUE, or 1 to a boolean database field is perfectly acceptable in many systems. And concerning your last statement: PHP should never under any circumstance attempt to think for the programmer. I expect a database abstraction layer to pass parameters along transparently *because* it is an abstraction layer. A programming language is not smarter than the one who implements it, and it is impossible to mitigate an error in logic. Rather, it is better for an error to be returned in order so that the erroneous logic be corrected, as their may be an even greater issue at hand. In closing, I believe that the implementation of a patch for this issue would be more inline with the general philosophy and design patterns that govern PHP than the current functionality today, to the point that I maintain my position that the current functionality is in fact buggy. I merely ask that PDO -- true to the form and function of an abstraction layer -- would pass parameters along in their respective data types without casting them to "string" of all things. I thank everyone who has participated in this issue thus far (especially sjored for the patch submitted), and am looking forward to this issue being resolved in an upcoming release. [2009-10-04 18:46:07] sjo...@php.net It is a bad idea to determine the PDO type from the PHP type. First, it would break existing scripts which assume false is cast to an empty string, like this: $a[] = strstr($foo, $bar); // may return false $pdo->execute($a); Secondly, the correct type to use is the type of the column, not the type of the PHP parameter. Consider the following query: SELECT * FROM foo WHERE a=? If a is a boolean, the parameter to execute() or bindBaram() should be converted to a boolean, no matter what the type of the passed parameter is. Finally, one of PHP features is that it dynamically changes types. The type of a variable should be transparent to the user. Therefore, the behavior of a function should not change when it is passed another type. To solve this, you should always specify the PDO type. Only the programmer knows which types the column in the query have, PHP can not determine this automatically. [2009-09-22 18:31:34] sjo...@php.net Currently, every variable is assumed to be PDO_PARAM_STR. This patch changes this to PDO_PARAM_INT or PDO_PARAM_BOOL if the passed variable is a long or a bool, respectively. http://www.gissen.nl/files/bug44597.patch This may break existing scripts, which depend on false being converted to an empty string. -------- [2009-09-21 19:48:55] kenaniah at gmail dot com In response to sjoerd, this may very well be a product of bad documentation, but that does not exclude the functional use case. One could reasonably claim that proper detection of parameter types should in fact be part of the functional definition of execute(). Virt
#44597 [Com]: Postgres driver does not prepare booleans correctly
ID: 44597
Comment by: kenaniah at gmail dot com
Reported By: kenaniah at gmail dot com
Status: Open
Bug Type: PDO related
Operating System: Red Hat 4.1.1
PHP Version: 5.2.5
New Comment:
This issue seems like it would be a very easy fix and can be reproduced
without fail, regardless of server environment or PHP version.
A fix would be greatly appreciated
Previous Comments:
[2008-10-07 19:23:48] dac514 at hotmail dot com
This is happening to me too, OS X and CentOS, PHP 5.2.6
I am converting a web application from MySql to PostgreSQL and i've
run into a roadbloack that is forcing me to find every single boolean
query and manually binding it instead of benefiting from execute()
$input_parameters. PITA! I discovered the explanation to this "bug"
here:
http://ca.php.net/manual/en/pdostatement.execute.php#84990
As of 5.2.6 you still can't use PDOStatement->execute()
$input_parameters to pass a boolean to PostgreSQL. To do that, you'll
have to call bindParam() with explicit types for *each* parameter in
the query.
Pseudo example, where col5 is of type boolean (i.e. tinyint(1) in
MySQL)
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db->prepare($q);
$st->execute($v);
PostgreSQL complains and the script dies. Leaving me in the cold and I
have to rewrite the code, which becomes excessively painful when the
queries are dynamically generated. PostgreSQL workaround, boo!
$q = 'INSERT INTO table (col1, col2, col3, col4, col5, col6) VALUES (?
, ?, ?, ?, ?, ?)';
$v = array('foo1', 'foo2', 'foo3', foo4', false, 'foo6');
$st = $db->prepare($q);
$st->bindParam(1, $v[0]], PDO::PARAM_STR);
$st->bindParam(2, $v[1]], PDO::PARAM_STR);
$st->bindParam(3, $v[2]], PDO::PARAM_STR);
$st->bindParam(4, $v[3]], PDO::PARAM_STR);
$st->bindParam(5, $v[4]], PDO::PARAM_BOOL);
$st->bindParam(6, $v[5]], PDO::PARAM_STR);
$st->execute();
Can we get a fix for this soon?
[2008-04-01 21:00:50] kenaniah at gmail dot com
Description:
When using postgres via PDO and attempting to execute an INSERT or
UPDATE query using $stmt->execute(array_values($data)) syntax, postgres
returns an error for any boolean fields that may be present.
Reproduce code:
---
prepare($sql);
$stmt->execute($values);
?>
Expected result:
PDO will recognize that the values in the array are boolean, and will
provide these values to the prepared statement as correctly-formatted
booleans.
Actual result:
--
PostgreSQL 8.1.9 returns an error stating that the provided values for
the booleans are not in the correct format, and may need to be
type-casted.
--
Edit this bug report at http://bugs.php.net/?id=44597&edit=1
#47615 [NEW]: PDO parameter binding is in clear violation of the ISO 9075 standard
From: kenaniah at gmail dot com
Operating system: *
PHP version: 5.2.9
PHP Bug Type: PDO related
Bug description: PDO parameter binding is in clear violation of the ISO 9075
standard
Description:
Referencing ISO 9075, PDO does not properly bind boolean parameters when
the parameter type has not been made known to PDO.
According to the standard, booleans represent a truth, false, or unknown
value. According to the SQL language definition (feel free to reference
SQL-92), the SQL equivalents for a boolean value are TRUE, FALSE, and NULL
respectively.
The PDO core should automatically convert boolean values to their proper
SQL counterparts, and it should be the role of the client driver to deal
with these values if the database platform in question does not support the
ISO standard.
Rather than listing workarounds, we ask that the PDO core be brought into
compliance with the SQL standards, and that individual database drivers be
modified to handle the cases in which their underlying database is not
standards compliant.
Reproduce code:
---
$res = $db->prepare('SELECT id FROM table WHERE mybool = ?');
$res->execute(array(false));
Expected result:
SQL statement sent to server:
SELECT id FROM table WHERE mybool = FALSE
(unless modified by DB driver due to a lack of standards compliance on the
part of the DB)
Actual result:
--
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for type boolean: ""'
^^for Postgres driver (Postgres is an standard compliant DB as far as
booleans are concerned)
--
Edit bug report at http://bugs.php.net/?id=47615&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47615&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47615&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47615&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47615&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47615&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47615&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47615&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47615&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47615&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47615&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47615&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47615&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47615&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47615&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47615&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47615&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47615&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47615&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47615&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47615&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47615&r=mysqlcfg
[PHP-BUG] Req #51451 [NEW]: Native interface for date/time functions
From:
Operating system: *
PHP version: 5.3.2
Package: Date/time related
Bug Type: Feature/Change Request
Bug description:Native interface for date/time functions
Description:
I would love to see interfaces defined in core that would allow any
implementing object to be passed parameters to date/time functions when
applicable, very similar to the way Countable allows any implementing
object to be count()'ed.
For example, an interface such as Timestampable may allow implementing
objects a method by which they may produce a timestamp for usage in all PHP
core date/time functions that accept a timestamp parameter. The interface
would define a single method called timestamp() expected to return an
integer value representing the timestamp to be used.
Any core PHP date/time functions that previously accepted only integers for
timestamps should be extended to allow for objects that implement the
Timestampable interface as well.
Finally, DateTime should implement this interface natively, allowing it to
be passed directly to functions such as date() without modification.
Test script:
---
format("c"); //2008-10-14T18:24:00-04:00
print date("c", strtotime($string)); //2008-10-14T15:24:00-07:00
print date("c", $date); //2008-10-14T15:24:00-07:00
class Foo implements Timestampable {
function timestamp(){
return 127; //Returns timestamp to be used
}
}
$obj = new Foo;
print date("c", $obj); //1970-01-15T08:46:40-08:00
?>
--
Edit bug report at http://bugs.php.net/bug.php?id=51451&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51451&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51451&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51451&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51451&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51451&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51451&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51451&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51451&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51451&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51451&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51451&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51451&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51451&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51451&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51451&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51451&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51451&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51451&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51451&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51451&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51451&r=mysqlcfg
#50726 [NEW]: Resume after Exceptions
From: kenaniah at gmail dot com Operating system: Linux PHP version: 5.3.1 PHP Bug Type: Feature/Change Request Bug description: Resume after Exceptions Description: I think that PHP would benefit greatly by implementing a feature known as "resumeable" exceptions. The end goal would be to provide a method by which code execution may be continued from the point at which an exception was thrown. Naturally, some exceptions should not be resumeable by nature, which would require an extension to the Exception class of a simple boolean property indicating whether an instance of that exception can be resumed or not. The only real problem AFAICS with resumeable exceptions has to do with the state of the execution stack. Obviously, if execution were to be resumed after an exception is handled, the stack can not be unwound automatically (Schrodinger's cat, anyone?). My suggestion would be to allow another keyword besides "catch" (such as "resume") to handle exceptions. If a resumeable exception is thrown and caught in a "resume" block, the parser should proceed as if it were handling a function call. In short, the unwinding of the execution stack would need to be deferred until it is determined whether or not execution will be resumed at the point of the exception. -- Edit bug report at http://bugs.php.net/?id=50726&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50726&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50726&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50726&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50726&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50726&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50726&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50726&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50726&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50726&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50726&r=support Expected behavior: http://bugs.php.net/fix.php?id=50726&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50726&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50726&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50726&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50726&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50726&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50726&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50726&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50726&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50726&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50726&r=mysqlcfg
#50726 [Com]: Resume after Exceptions
ID: 50726 Comment by: kenaniah at gmail dot com Reported By: kenaniah at gmail dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 5.3.1 New Comment: I agree that this may be abuse of exceptions. Essentially, I am looking for some sort of flow control system that allows me send messages, handle them, and yield control back to various points in the execution stack at my discretion. Previous Comments: [2010-01-12 00:16:31] degeb...@php.net An exception is by definition a state where the program no longer knows how to proceed. It's basically a way of saying "I give up, you'll have to handle this yourself". You have this ability using a try-catch block. Exceptions shouldn't be used to control the application flow, but should be used for genuinely exceptional situations. In my opinion, if a try-catch block doesn't satisfy your needs, you are more than likely misusing exceptions. ---- [2010-01-11 23:53:02] kenaniah at gmail dot com Description: I think that PHP would benefit greatly by implementing a feature known as "resumeable" exceptions. The end goal would be to provide a method by which code execution may be continued from the point at which an exception was thrown. Naturally, some exceptions should not be resumeable by nature, which would require an extension to the Exception class of a simple boolean property indicating whether an instance of that exception can be resumed or not. The only real problem AFAICS with resumeable exceptions has to do with the state of the execution stack. Obviously, if execution were to be resumed after an exception is handled, the stack can not be unwound automatically (Schrodinger's cat, anyone?). My suggestion would be to allow another keyword besides "catch" (such as "resume") to handle exceptions. If a resumeable exception is thrown and caught in a "resume" block, the parser should proceed as if it were handling a function call. In short, the unwinding of the execution stack would need to be deferred until it is determined whether or not execution will be resumed at the point of the exception. -- Edit this bug report at http://bugs.php.net/?id=50726&edit=1
[PHP-BUG] Req #51308 [NEW]: PDO::FETCH_FUNC should also work with fetch()
From:
Operating system: *
PHP version: 5.3.2
Package: PDO related
Bug Type: Feature/Change Request
Bug description:PDO::FETCH_FUNC should also work with fetch()
Description:
Currently, PDO::FETCH_FUNC can only be used in the PDOStatement::fetchAll()
method. This fetch mode, however, is essentially useless since it can not
be set using setFetchMode() or fetch(), and thus can not be used in
iteration.
Test script:
---
execute("SELECT * FROM foobar");
$stmt->setFetchMode(PDO::FETCH_FUNC, 'var_dump');
foreach($stmt as $row):
...
endforeach;
?>
Expected result:
PDO should set the fetch mode to FETCH_FUNC, and should call var_dump()
when $stmt is iterated. Because no additional fetch modes were passed to
setFetchMode(), var_dump() should receive an argument representing the row
in PDO::FETCH_BOTH format. $row should be set to the return of var_dump(),
and control should now be passed to the foreach codeblock.
IMHO, FETCH_FUNC should allow one to provide a callback function that
allows full manipulation of the row before being passed into the iteration
codeblock. For example, in an active record implementation, one would have
to set the FETCH_CLASS method and suffer a very costly object
instantiation. A callback function would allow me to clone an existing (and
fully loaded) object, set my properties, and return it -- saving me upwards
of 90% in execution costs for heavy objects.
Actual result:
--
Warning: PDOStatement::setFetchMode() [pdostatement.setfetchmode]:
SQLSTATE[HY000]: General error: PDO::FETCH_FUNC is only allowed in
PDOStatement::fetchAll()
--
Edit bug report at http://bugs.php.net/bug.php?id=51308&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51308&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51308&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51308&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51308&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51308&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51308&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51308&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51308&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51308&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51308&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51308&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51308&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51308&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51308&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51308&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51308&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51308&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51308&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51308&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51308&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51308&r=mysqlcfg
Req #51308 [Opn]: PDO::FETCH_FUNC should also work with fetch()
Edit report at http://bugs.php.net/bug.php?id=51308&edit=1
ID: 51308
User updated by:kenaniah at gmail dot com
Reported by:kenaniah at gmail dot com
Summary:PDO::FETCH_FUNC should also work with fetch()
Status: Open
Type: Feature/Change Request
Package:PDO related
Operating System: *
PHP Version:5.3.2
Block user comment: N
New Comment:
jinmoku:
Thanks, but that doesn't solve the problem. Consider the use case in
which you
would want to transparently process database results between the
database and
PHP. By implementing FETCH_FUNC, one would be able to process the result
set
without having to modify every instance where the result is accessed.
Your
workaround requires that I modify my code every place I want to
pre-process my
results, as opposed to simply modifying the fetch mode on the driver
once. As
you could imagine, the workaround would be more of a headache than the
actual
bug in a fairly-sized codebase.
Previous Comments:
[2010-11-15 01:07:45] jinmoku at hotmail dot com
you can use call_user_func_array :
$db = new PDO(...);
$stmt = $db->execute("SELECT * FROM foobar");
$stmt->setFetchMode(PDO::FETCH_ASSOC);
foreach($stmt as $row):
call_user_func_array('var_dump', $row);
endforeach;
[2010-11-13 12:41:14] visor at alt22 dot ru
Still reproduced for PHP 5.3.3
----
[2010-03-16 18:24:20] kenaniah at gmail dot com
Description:
Currently, PDO::FETCH_FUNC can only be used in the
PDOStatement::fetchAll() method. This fetch mode, however, is
essentially useless since it can not be set using setFetchMode() or
fetch(), and thus can not be used in iteration.
Test script:
---
execute("SELECT * FROM foobar");
$stmt->setFetchMode(PDO::FETCH_FUNC, 'var_dump');
foreach($stmt as $row):
...
endforeach;
?>
Expected result:
PDO should set the fetch mode to FETCH_FUNC, and should call var_dump()
when $stmt is iterated. Because no additional fetch modes were passed to
setFetchMode(), var_dump() should receive an argument representing the
row in PDO::FETCH_BOTH format. $row should be set to the return of
var_dump(), and control should now be passed to the foreach codeblock.
IMHO, FETCH_FUNC should allow one to provide a callback function that
allows full manipulation of the row before being passed into the
iteration codeblock. For example, in an active record implementation,
one would have to set the FETCH_CLASS method and suffer a very costly
object instantiation. A callback function would allow me to clone an
existing (and fully loaded) object, set my properties, and return it --
saving me upwards of 90% in execution costs for heavy objects.
Actual result:
--
Warning: PDOStatement::setFetchMode() [pdostatement.setfetchmode]:
SQLSTATE[HY000]: General error: PDO::FETCH_FUNC is only allowed in
PDOStatement::fetchAll()
--
Edit this bug report at http://bugs.php.net/bug.php?id=51308&edit=1
#44597 [NEW]: Postgres driver does not prepare booleans correctly
From: kenaniah at gmail dot com Operating system: Red Hat 4.1.1 PHP version: 5.2.5 PHP Bug Type: PDO related Bug description: Postgres driver does not prepare booleans correctly Description: When using postgres via PDO and attempting to execute an INSERT or UPDATE query using $stmt->execute(array_values($data)) syntax, postgres returns an error for any boolean fields that may be present. Reproduce code: --- prepare($sql); $stmt->execute($values); ?> Expected result: PDO will recognize that the values in the array are boolean, and will provide these values to the prepared statement as correctly-formatted booleans. Actual result: -- PostgreSQL 8.1.9 returns an error stating that the provided values for the booleans are not in the correct format, and may need to be type-casted. -- Edit bug report at http://bugs.php.net/?id=44597&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=44597&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=44597&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=44597&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=44597&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=44597&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=44597&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=44597&r=needscript Try newer version:http://bugs.php.net/fix.php?id=44597&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=44597&r=support Expected behavior:http://bugs.php.net/fix.php?id=44597&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=44597&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=44597&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=44597&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=44597&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=44597&r=dst IIS Stability:http://bugs.php.net/fix.php?id=44597&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=44597&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=44597&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=44597&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=44597&r=mysqlcfg
#42535 [NEW]: repeat() loop
From: kenaniah at gmail dot com
Operating system:
PHP version: 5.2.4
PHP Bug Type: Feature/Change Request
Bug description: repeat() loop
Description:
Granted, you can replicate this by using
while($i=0;$i<$times;$i++){
//code here
}
but that defeats the doctrine of simplicity...
Is a language construct such as
repeat($times){
//code here
}
really that much to ask for?
My proposal:
void repeat ($times, [&$counter]) where
counter is a reference to a variable that will be incremented upon each
iteration.
--
Edit bug report at http://bugs.php.net/?id=42535&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42535&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42535&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42535&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42535&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42535&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42535&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42535&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42535&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42535&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42535&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42535&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42535&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42535&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42535&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42535&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42535&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42535&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42535&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42535&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42535&r=mysqlcfg
#31690 [Com]: user specific additions to php.ini
ID: 31690 Comment by: kenaniah at gmail dot com Reported By: wf at bitplan dot com Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5.0.3 New Comment: I am somewhat surprised to see that PHP can't do this yet. It is definitely something I could use. Previous Comments: [2007-06-06 22:27:43] revan02 at googlemail dot com This kind of feature request would be great on any os. I've discovered the same issue and it would be great to hear a response because it's now some time ago that this CR has been submitted. [2005-02-09 15:13:26] rb at bitplan dot com we are developing a product and we need that feature badly. The goal is to have our own section in php.ini. [2005-01-25 20:11:20] wf at bitplan dot com Description: a) When adding user specific entries to php.ini these are not returned. b) the location of php.ini is not available via a standard function The combination of a + b makes it almost impossible to have user specific additions to php.ini So ini_get() should allow to read user specific entries and/or the php.ini location should be available as a variable or via ini_get Reproduce code: --- a) php.ini contains: uml2phphome = "c:/Programme/BITPlan/UML2PHP" b) echo PHP_INI_PATH; Expected result: a) c:/Programme/BITPlan/UML2PHP b) c:/Windows/PHP.INI on my windows machine /usr/local/lib/php5.0.3/php.ini on my linux machine Actual result: -- nothing -- Edit this bug report at http://bugs.php.net/?id=31690&edit=1
#42536 [NEW]: Dynamic and multiple object inheritance (and no, this isn't heresy)
From: kenaniah at gmail dot com
Operating system:
PHP version: 5.2.4
PHP Bug Type: Feature/Change Request
Bug description: Dynamic and multiple object inheritance (and no, this isn't
heresy)
Description:
To implement this would require a definite change in the way PHP handles
objects, but it would be an excellent addition to the language if we were
able to modify the inheritances of an object after its initialization.
For example:
In an MVC framework, an object named 'User' is manipulated in the Model,
and needs to be saved to the database. Instead of extending 'User' from an
Active Record Database Object class, one could extend the instantiated
'User' object to include the Active Record Class, perform the database
queries, and then "disinherit" the class before passing control on to the
View, eliminating the ability to make use of the Active Record class'
features from within the View.
Proposed functions:
extend ( object $object, string $class ) -- dynamically extends $object
from $class
unextend ( object $object, string $class ) -- removes $class from object
(no longer a parent to $object)
adopt ( object $object, string $class ) -- $class is added to $object as
an extension
unadopt ( object $object, string $class ) -- removes $class from $object
(no longer a child within $object)
Reproduce code:
---
class User{
...
}
class ActiveRecord{
...
}
$user = new User;
$user->name = "New Name";
extend($user, "ActiveRecord"); //$user is now extended from ActiveRecord
$user->save(); //a function from ActiveRecord class
unextend($user, "ActiveRecord"); //ActiveRecord is completely removed from
$user
--
Edit bug report at http://bugs.php.net/?id=42536&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=42536&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=42536&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=42536&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42536&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=42536&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=42536&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42536&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42536&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=42536&r=support
Expected behavior:http://bugs.php.net/fix.php?id=42536&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=42536&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=42536&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42536&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=42536&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42536&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42536&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=42536&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=42536&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=42536&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42536&r=mysqlcfg
