Req #62911 [Com]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Comment by: willfi...@php.net Reported by:bdurand-php at ssji dot net Summary:Add DateTime::__toString() Status: Assigned Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant Assigned To:willfitch Block user comment: N Private report: N New Comment: This is a good idea. I will add this, but will also add an RFC as I'd like the input of other internals on the output format. Previous Comments: [2012-08-23 18:15:37] bdurand-php at ssji dot net Description: Hello, I want to have a default behavior to convert an instance of the class DateTime into a string. I mean implement the method __toString() in the DateTime class. The default format should be ISO8601 IMHO, but we can add an attribut to define the default format to use for __toString() and format() method. Greetings. Test script: --- https://bugs.php.net/bug.php?id=62911&edit=1
Req #62911 [Com]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Comment by: willfi...@php.net Reported by:bdurand-php at ssji dot net Summary:Add DateTime::__toString() Status: Wont fix Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant Assigned To:willfitch Block user comment: N Private report: N New Comment: It's not a matter of whether PHP can or not; it's a matter of gathering a consensus among developers on what standard *should* be default. I personally agree with adding __tostring, but this needs to be proposed in an RFC, which I will do tonight. Previous Comments: [2012-08-27 17:27:15] bdurand-php at ssji dot net The timezone can be defined in the constructor, with the directive tz php.ini, or with date_default_timezone_get() function. A DateTime is a string in fact, so it's logic to have a string cast available. Which format is more standard than ISO format? Another common format is the timestamp, but it can not represent all dates. Other languages did this behavior ââlike python. Why PHP can't? I know that I can subclass any (core) class... it's not the problem here. ---- [2012-08-27 15:24:45] willfi...@php.net Would it be worth investing time in adding a setter/constructor option for a default format type? Setting no default could fallback to one of the constants (which still doesn't resolve the non-consensus issue). [2012-08-27 15:17:38] der...@php.net We have had this a few times now, and we should not do this. The main reason is that we will never be able to come to a consensus on which format to show. It certainly shouldn't have anything that destroys the encoded timezone identifiers. It's perfectly possible to subclass DateTime yourself and add a __toString() that returns the datetime in your preferred format though. -------- [2012-08-27 15:15:15] willfi...@php.net This is a good idea. I will add this, but will also add an RFC as I'd like the input of other internals on the output format. [2012-08-23 18:15:37] bdurand-php at ssji dot net Description: Hello, I want to have a default behavior to convert an instance of the class DateTime into a string. I mean implement the method __toString() in the DateTime class. The default format should be ISO8601 IMHO, but we can add an attribut to define the default format to use for __toString() and format() method. Greetings. Test script: --- https://bugs.php.net/bug.php?id=62911&edit=1
Bug #62593 [Com]: Emulate prepares behave strangely with PARAM_BOOL
Edit report at https://bugs.php.net/bug.php?id=62593&edit=1
ID: 62593
Comment by: willfi...@php.net
Reported by:mascione at sviluppo dot toscana dot it
Summary:Emulate prepares behave strangely with PARAM_BOOL
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04
PHP Version:5.3.14
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
I have confirmed this. The issue with disabling emulation prepares for this
purpose is that it sends the query through PQprepare, then PQexec. If you're
using middleware such as pgbouncer, this won't work.
Previous Comments:
[2012-07-19 06:15:02] ploginoff at gmail dot com
Yes! _Yesterday_ I have * with the same bug. Solution: install 5.3.13 or
disable emulate prepares (but it is sometimes necessary).
[2012-07-18 10:04:51] mascione at sviluppo dot toscana dot it
Description:
On postgresql when I use ATTR_EMULATE_PREPARES binding params or values with
PARAM_BOOL behave strangely.
Disabling ATTR_EMULATE_PREPARES resolve the problem.
(driver specific PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT generates same
problem)
(Related to bug #38386 ?)
Test script:
---
$db = new PDO('pgsql:dbname=testdb;user=postgres');
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
//$db->setAttribute(PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT, true);
//CREATE TABLE t(a boolean, b boolean)
$stmt = $db->prepare("INSERT INTO t(a,b) VALUES (true,false)");
$stmt->execute();
print_r($stmt->errorInfo());
$stmt = $db->prepare("INSERT INTO t(a,b) VALUES (:test,:test)");
$stmt->bindValue('test', false, PDO::PARAM_BOOL);
$stmt->execute();
print_r($stmt->errorInfo());
$stmt = $db->prepare("SELECT * FROM t WHERE :test");
$stmt->bindValue('test', true, PDO::PARAM_BOOL);
$stmt->execute();
print_r($stmt->errorInfo());
print_r($stmt->fetchAll());
Expected result:
Works without errors.
Actual result:
--
Array
(
[0] => 0
[1] =>
[2] =>
)
Array
(
[0] => 42804
[1] => 7
[2] => ERROR: column "a" is of type boolean but expression is of type
integer
LINE 1: INSERT INTO t(a,b) VALUES (0,'0')
^
HINT: You will need to rewrite or cast the expression.
)
Array
(
[0] => 42804
[1] => 7
[2] => ERROR: argument of WHERE must be type boolean, not type integer
LINE 1: SELECT * FROM t WHERE 1
^
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62593&edit=1
Bug #62479 [Com]: PDO-psql cannot connect if password contains spaces
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1 ID: 62479 Comment by: willfi...@php.net Reported by:brice at bmaron dot net Summary:PDO-psql cannot connect if password contains spaces Status: Verified Type: Bug Package:PDO related Operating System: Linux- Debian Stable PHP Version:5.3.14 Assigned To:willfitch Block user comment: N Private report: N New Comment: I have confirmed your findings. Let me do a little sniffing around and see what I can come up with. Previous Comments: [2012-07-04 12:29:56] brice at bmaron dot net It seems to be a pdo-psql only ... not affecting other drivers like mysql [2012-07-04 08:56:06] brice at bmaron dot net Description: When you try to connect to a Postgresql database with a password containing 1 or more spaces, pdo will fail to connect. You must escape yourself the user & password and put it into the dsn to make it work. It may also be true for other databases ... it's not tested Test script: --- https://gist.github.com/3046155 Expected result: See a connection and no error for both tries Actual result: -- See an error for the first one and a correct result for the second one -- Edit this bug report at https://bugs.php.net/bug.php?id=62479&edit=1
Bug #60515 [Com]: "Invalid parameter number" although it is correct
Edit report at https://bugs.php.net/bug.php?id=60515&edit=1
ID: 60515
Comment by: willfi...@php.net
Reported by:phoenixseve at freenet dot de
Summary:"Invalid parameter number" although it is correct
Status: Open
Type: Bug
Package:PDO related
Operating System: archlinux x86_64
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
After removing the invalid quote from your SQL statement, there is no issue
here.
I tried this with MySQL and PostgreSQL drivers. Please confirm.
Previous Comments:
[2012-05-02 11:21:11] u...@php.net
$stmt = $pdo->prepare("UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24'");
Your SQL is invalid.
Whatever is behind, parsing is done by the PDO core. Thus, this is most
unlikely to be MySQL specific. Parsing needs to be done as a syntax is used
that is not supported by MySQL. Replace MySQL here with any other DB that does
not support named parameters or do the same with questionmarks and a DB that
does support named parameters only but no questionmarks.
[2012-03-06 02:35:34] jeffvanb at u dot washington dot edu
This misleading error message is also thrown when you include a single-line
comment that contains a single-quote.
Example:
SELECT something
-- This valid SQL syntax shouldn't be a problem
FROM somewhere
WHERE value = :v;
PDO will tell you the parameter count is mismatched and you will pull your hair
out wondering what is wrong.
[2011-12-13 20:57:47] phoenixseve at freenet dot de
Description:
When I execute the attached test script an exception is thrown with the message:
SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens
The exception is raised in the execute() line.
If you change the WHERE clause to `id`=24 there is no error message.
The same is true for this query: UPDATE `edtable` SET `id`=:p0 WHERE `id`='24'
The generated error message is obviously not correct. I don't even see why an
error message is generated as the request seems valid (although strange) to me.
Test script:
---
$createTableSql = <<<'EOT'
DROP TABLE IF EXISTS `edtable`;
CREATE TABLE IF NOT EXISTS `edtable` (
`id` bigint(20) NOT NULL,
`coun't()` varchar(20) NOT NULL
);
EOT;
$pdo = new PDO('mysql:host=localhost;dbname=aynte','aynte','aynte');
$pdo->setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$result = $pdo->query($createTableSql);
$result->closeCursor();
$stmt = $pdo->prepare("UPDATE `edtable` SET `id`=:p0, `coun't()`= :p1 WHERE
`id`='24'");
$stmt->execute(array(':p0'=>'2', ':p1'=>'b2' ));
Expected result:
No error message.
Actual result:
--
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY093]: Invalid parameter number: number of bound variables does not
match number of tokens' in /srv/http/test.php:19\nStack trace:\n#0
/srv/http/test.php(19): PDOStatement->execute(Array)\n#1 {main}\n thrown in
/srv/http/test.php on line 19
--
Edit this bug report at https://bugs.php.net/bug.php?id=60515&edit=1
Bug #62593 [Com]: Emulate prepares behave strangely with PARAM_BOOL
Edit report at https://bugs.php.net/bug.php?id=62593&edit=1
ID: 62593
Comment by: willfi...@php.net
Reported by:mascione at sviluppo dot toscana dot it
Summary:Emulate prepares behave strangely with PARAM_BOOL
Status: Verified
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04
PHP Version:5.3.14
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
This was accepted and is awaiting merge.
Previous Comments:
[2012-09-20 16:36:16] willfi...@php.net
Pull request for this fix:
https://github.com/php/php-src/pull/198
[2012-09-18 10:04:19] v dot picture at free dot fr
Same problem with the stock version on Ubuntu 12.04: PHP 5.3.10-1ubuntu3.4
(built: Sep 12 2012)
I hope this problem will be solved soon.
[2012-09-17 16:17:24] willfi...@php.net
I have confirmed this. The issue with disabling emulation prepares for this
purpose is that it sends the query through PQprepare, then PQexec. If you're
using middleware such as pgbouncer, this won't work.
[2012-07-19 06:15:02] ploginoff at gmail dot com
Yes! _Yesterday_ I have * with the same bug. Solution: install 5.3.13 or
disable emulate prepares (but it is sometimes necessary).
[2012-07-18 10:04:51] mascione at sviluppo dot toscana dot it
Description:
On postgresql when I use ATTR_EMULATE_PREPARES binding params or values with
PARAM_BOOL behave strangely.
Disabling ATTR_EMULATE_PREPARES resolve the problem.
(driver specific PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT generates same
problem)
(Related to bug #38386 ?)
Test script:
---
$db = new PDO('pgsql:dbname=testdb;user=postgres');
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
//$db->setAttribute(PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT, true);
//CREATE TABLE t(a boolean, b boolean)
$stmt = $db->prepare("INSERT INTO t(a,b) VALUES (true,false)");
$stmt->execute();
print_r($stmt->errorInfo());
$stmt = $db->prepare("INSERT INTO t(a,b) VALUES (:test,:test)");
$stmt->bindValue('test', false, PDO::PARAM_BOOL);
$stmt->execute();
print_r($stmt->errorInfo());
$stmt = $db->prepare("SELECT * FROM t WHERE :test");
$stmt->bindValue('test', true, PDO::PARAM_BOOL);
$stmt->execute();
print_r($stmt->errorInfo());
print_r($stmt->fetchAll());
Expected result:
Works without errors.
Actual result:
--
Array
(
[0] => 0
[1] =>
[2] =>
)
Array
(
[0] => 42804
[1] => 7
[2] => ERROR: column "a" is of type boolean but expression is of type
integer
LINE 1: INSERT INTO t(a,b) VALUES (0,'0')
^
HINT: You will need to rewrite or cast the expression.
)
Array
(
[0] => 42804
[1] => 7
[2] => ERROR: argument of WHERE must be type boolean, not type integer
LINE 1: SELECT * FROM t WHERE 1
^
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=62593&edit=1
Bug #63212 [Com]: <' breaks strip_tags()
Edit report at https://bugs.php.net/bug.php?id=63212&edit=1 ID: 63212 Comment by: willfi...@php.net Reported by:dac dot chartrand at gmail dot com Summary: <' breaks strip_tags() Status: Open Type: Bug Package:*General Issues PHP Version:5.4.7 Block user comment: N Private report: N New Comment: @riptide - no. is in the list of allowable tags. I'll look into this one this evening. Previous Comments: [2012-10-04 17:44:38] riptide dot tempora at opinehub dot com "Expected result: Hello WorldShould be removedGoodbye World Actual result: -- Hello WorldShould" Shouldn't that (.*) be eliminated to? :\ [2012-10-04 02:16:26] pierr...@php.net Hi Daniel, You're right, the ' is actually opening a quote which is never closed. But in a valid html/xml, having something like this : <'foo'> is now allowed. We could maybe verify that the node have a name before accepting an opening quote. [2012-10-04 01:56:16] dac dot chartrand at gmail dot com Hi Pierrick I disagree. Maybe my report needs more info. Here are two other examples: -=-=- $content = "Hello WorldShould <# > be removed Goodbye World"; $content = strip_tags($content, ' '); echo $content; // Hello WorldShould be removedGoodbye World $content = "Hello WorldShould <' > be removed Goodbye World"; $content = strip_tags($content, ' '); echo $content; // Hello WorldShould -=-=- Thanks for looking into this. [2012-10-03 23:34:14] pierr...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Hi Daniel, I don't think this is a bug. You're opening a tag which is not terminated. So strip_tags will strip it. If you replace your <' by any other char (but space) like '); echo $content; // Good // Hello WorldShould be removedGoodbye World $content = "Hello WorldShould <' be removedGoodbye World"; $content = strip_tags($content, ''); echo $content; // Bad // Hello WorldShould Expected result: Hello WorldShould be removedGoodbye World Actual result: -- Hello WorldShould -- Edit this bug report at https://bugs.php.net/bug.php?id=63212&edit=1
Bug #62479 [Com]: PDO-psql cannot connect if password contains spaces
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1 ID: 62479 Comment by: willfi...@php.net Reported by:brice at bmaron dot net Summary:PDO-psql cannot connect if password contains spaces Status: Verified Type: Bug Package:PDO related Operating System: Linux- Debian Stable PHP Version:5.3.14 Assigned To:willfitch Block user comment: N Private report: N New Comment: Thanks Iliaa - I will update the pull request to take into account escaping backslashes as well. Previous Comments: [2012-10-31 01:53:20] il...@php.net I think the attached patch maybe slightly better than the one proposed, the attached patch also accounts for passwords that may contain \ character inside them. [2012-10-31 01:51:40] il...@php.net The following patch has been added/updated: Patch Name: PDOPostgreSQLPassword Revision: 1351648300 URL: https://bugs.php.net/patch-display.php?bug=62479&patch=PDOPostgreSQLPassword&revision=1351648300 [2012-09-20 20:12:00] willfi...@php.net Pull request for this bug has been submitted at: https://github.com/php/php- src/pull/199. [2012-09-17 19:39:08] willfi...@php.net I have confirmed your findings. Let me do a little sniffing around and see what I can come up with. [2012-07-04 12:29:56] brice at bmaron dot net It seems to be a pdo-psql only ... not affecting other drivers like mysql 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 https://bugs.php.net/bug.php?id=62479 -- Edit this bug report at https://bugs.php.net/bug.php?id=62479&edit=1
Bug #63642 [Com]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Comment by: willfi...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
Block user comment: N
Private report: N
New Comment:
Without looking into this too far, have you verified that
error_reporting/display_errors are set to levels that are sufficient to display
or
record this error?
Previous Comments:
[2012-11-29 00:25:41] amex at bucksvsbytes dot com
Description:
In PHP 5.3.10 and PostgreSQL 9.1, when executing PDOStatement::fetchAll(), if
the retrieved data busts the PHP memory limit, the script dies quietly, without
throwing an "out of memory" error.
Test script:
---
//ini_set('memory_limit','256M');
$dsn=;//appropriate Data Source Name string
$sql=;//any query that returns slightly more data than the PHP memory limit
allows (default limit is 128 MB on my server)
$db=new PDO($dsn);
$result=$db->query($sql);
$datarray=$result->fetchAll();//fetch all rows into an array
Expected result:
When fetchAll() retrieves too much data, the script dies quietly, instead of
throwing an "out of memory" error.
When I uncomment the first line, the script runs to completion, thus proving
that the quiet death was due to lack of memory.
The problem seems to relate to the postgresql driver, as the same thing happens
when I use pg_connect/pg_query/pg_fetch_all instead of PDO to get data from the
same query.
This is the only PHP "out of memory" condition I've ever seen where no error is
thrown.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63642&edit=1
