Bug #62571 [NoF->Csd]: Postgres PDO connections fail after SIGCHLD called
Edit report at https://bugs.php.net/bug.php?id=62571&edit=1 ID: 62571 Updated by: willfi...@php.net Reported by:spiros_ioannou at yahoo dot gr Summary:Postgres PDO connections fail after SIGCHLD called -Status: No Feedback +Status: Closed Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.14 Assigned To:willfitch Block user comment: N Private report: N Previous Comments: [2013-10-30 23:25:49] willfi...@php.net Closing as no feedback has been provided since I asked for it in 2012. [2012-12-18 21:23:52] willfi...@php.net Can you provide a test script for your issue? [2012-07-21 11:46:39] spiros_ioannou at yahoo dot gr When using persistent connections, even if reopening a new connection *after* forking, the connection fails. The only way to have DB connections is to reopen them after forking, with PDO::ATTR_PERSISTENT => false [2012-07-16 00:12:14] spiros_ioannou at yahoo dot gr I revoke the statement of SIGCHLD, it happens even without the handler in some situations, the behaviour seems erratic. Perhaps the database connection is shared with the children, and when the child dies the db variable the connection is closed. I tried closing the DB connection first thing on the child but with no results, the error still appears when the child dies. [2012-07-15 23:27:50] spiros_ioannou at yahoo dot gr Description: When using pcntl_fork to fork children, and *only* the parent uses the Postgres PDO database connection, the connection becomes unusable after the first child exits and the signal handler is called. If SIGCHLD signal handler is omitted PDO works normally for parent. Tested with and without persistent connections. Possible relevant bugs: 48447, 45797 Actual result: -- PHP Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 7 server closed the connection unexpectedly This probably means the server terminated abnormally -- Edit this bug report at https://bugs.php.net/bug.php?id=62571&edit=1
Bug #62639 [Opn->Asn]: XML structure broken
Edit report at https://bugs.php.net/bug.php?id=62639&edit=1 ID: 62639 Updated by: willfi...@php.net Reported by:alexshock at yandex dot ru Summary:XML structure broken -Status: Open +Status: Assigned Type: Bug Package:SimpleXML related Operating System: debian 6.0.5 PHP Version:5.4.5 -Assigned To: +Assigned To:willfitch Block user comment: N Private report: N Previous Comments: [2012-07-23 11:16:31] alexshock at yandex dot ru Description: In PHP 5.4.0 and higher SimpleXMLElement works strange when trying to obtain children nodes (see test.php source for details). Works fine in 5.3.x, I found that this issue occurs after this commit in php git repo: 1e3b32c777829f61fa9a18278e0647e9112d96ea Test script: --- https://www.dropbox.com/s/j0i47y7q4n4g0g6/test.php -- Edit this bug report at https://bugs.php.net/bug.php?id=62639&edit=1
Bug #62639 [Asn]: XML structure broken
Edit report at https://bugs.php.net/bug.php?id=62639&edit=1
ID: 62639
Updated by: willfi...@php.net
Reported by:alexshock at yandex dot ru
Summary:XML structure broken
Status: Assigned
Type: Bug
Package:SimpleXML related
Operating System: debian 6.0.5
PHP Version:5.4.5
Assigned To:willfitch
Block user comment: N
Private report: N
New Comment:
Confirmed in 5.4.5. In the process of verifying the change(s) that introduced
this issue:
object(A)#2 (1) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
}
object(A)#3 (2) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
[0]=>
string(10) "Some Value"
}
Previous Comments:
[2012-07-23 11:16:31] alexshock at yandex dot ru
Description:
In PHP 5.4.0 and higher SimpleXMLElement works strange when trying to obtain
children nodes (see test.php source for details).
Works fine in 5.3.x, I found that this issue occurs after this commit in php
git repo: 1e3b32c777829f61fa9a18278e0647e9112d96ea
Test script:
---
https://www.dropbox.com/s/j0i47y7q4n4g0g6/test.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=62639&edit=1
Bug #62639 [Asn]: XML structure broken
Edit report at https://bugs.php.net/bug.php?id=62639&edit=1
ID: 62639
Updated by: willfi...@php.net
Reported by:alexshock at yandex dot ru
Summary:XML structure broken
Status: Assigned
Type: Bug
Package:SimpleXML related
Operating System: debian 6.0.5
PHP Version:5.4.5
-Assigned To:willfitch
+Assigned To:acurioso
Block user comment: N
Private report: N
New Comment:
Andrew -
Would you mind taking a look at this? I reverted
1e3b32c777829f61fa9a18278e0647e9112d96ea locally, and array typecasting works
fine without the patch. Also, this patch causes the last child in an element
to
be skipped in the case pointed out in this
report. I wanted to get your input before I move forward with any changes.
Previous Comments:
[2012-07-27 21:27:52] willfi...@php.net
Confirmed in 5.4.5. In the process of verifying the change(s) that introduced
this issue:
object(A)#2 (1) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
}
object(A)#3 (2) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
[0]=>
string(10) "Some Value"
}
[2012-07-23 11:16:31] alexshock at yandex dot ru
Description:
In PHP 5.4.0 and higher SimpleXMLElement works strange when trying to obtain
children nodes (see test.php source for details).
Works fine in 5.3.x, I found that this issue occurs after this commit in php
git repo: 1e3b32c777829f61fa9a18278e0647e9112d96ea
Test script:
---
https://www.dropbox.com/s/j0i47y7q4n4g0g6/test.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=62639&edit=1
Bug #62639 [Asn]: XML structure broken
Edit report at https://bugs.php.net/bug.php?id=62639&edit=1
ID: 62639
Updated by: willfi...@php.net
Reported by:alexshock at yandex dot ru
Summary:XML structure broken
Status: Assigned
Type: Bug
Package:SimpleXML related
Operating System: debian 6.0.5
PHP Version:5.4.5
Assigned To:acurioso
Block user comment: N
Private report: N
New Comment:
I think that would make more sense. Thanks, Andrew.
Previous Comments:
[2012-07-30 00:58:13] acuri...@php.net
I can confirm that reverting that patch does fix the bug; however, it causes
the original test to fail again:
=
FAILED TEST SUMMARY
-
SimpleXML: cast to array [ext/simplexml/tests/034.phpt]
Bug #51615 (PHP crash with wrong HTML in SimpleXML)
[ext/simplexml/tests/bug51615.phpt]
=
See: ext/simplexml/tests/034.phpt for more information.
Ignore bug51615.phpt for now. That is just a side effect of test 34.
I would actually prefer if I could take the first stab at this bug myself since
it was clearly introduced in my code. I'd be hesitate to just revert the
changes since that would break test 34.
[2012-07-29 23:44:17] acuri...@php.net
After reverting locally do all the unit test cases for SimpleXML still pass?
This was not the case prior to the patch (one test was failing).
I'll work on reverting the change locally on my end tonight and see if I can
reproduce the bug and fix.
[2012-07-29 23:16:31] willfi...@php.net
Andrew -
Would you mind taking a look at this? I reverted
1e3b32c777829f61fa9a18278e0647e9112d96ea locally, and array typecasting works
fine without the patch. Also, this patch causes the last child in an element
to
be skipped in the case pointed out in this
report. I wanted to get your input before I move forward with any changes.
[2012-07-27 21:27:52] willfi...@php.net
Confirmed in 5.4.5. In the process of verifying the change(s) that introduced
this issue:
object(A)#2 (1) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
}
object(A)#3 (2) {
["@attributes"]=>
array(1) {
["attr"]=>
string(9) "Some Attr"
}
[0]=>
string(10) "Some Value"
}
[2012-07-23 11:16:31] alexshock at yandex dot ru
Description:
In PHP 5.4.0 and higher SimpleXMLElement works strange when trying to obtain
children nodes (see test.php source for details).
Works fine in 5.3.x, I found that this issue occurs after this commit in php
git repo: 1e3b32c777829f61fa9a18278e0647e9112d96ea
Test script:
---
https://www.dropbox.com/s/j0i47y7q4n4g0g6/test.php
--
Edit this bug report at https://bugs.php.net/bug.php?id=62639&edit=1
Bug #61025 [Opn]: __invoke() visibility not honored
Edit report at https://bugs.php.net/bug.php?id=61025&edit=1 ID: 61025 Updated by: willfi...@php.net Reported by:jpa...@php.net Summary:__invoke() visibility not honored Status: Open Type: Bug Package:Class/Object related Operating System: *nix PHP Version:5.3.10 Block user comment: N Private report: N New Comment: johannes - I can commit a fix for this, but at what point should it be introduced? Previous Comments: [2012-02-10 22:34:44] johan...@php.net Yes, the current behavior is wrong. I don't think it should be fixed in 5.3 though as the fix might break existing code. [2012-02-09 09:17:23] jpa...@php.net Description: __invoke() visibility is not honored when indirectly called as $obj(). It is, when directly called, via $obj->__invoke(); Please, note as well that declaring __invoke() as static works as well, I think it shouldn't (nonsense) Test script: --- __invoke(); */ Expected result: Call to private method Bar::__invoke() from context ... Actual result: -- Bar -- Edit this bug report at https://bugs.php.net/bug.php?id=61025&edit=1
Req #62911 [Wfx]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Updated 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: 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). Previous Comments: [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
Req #62911 [Wfx->ReO]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Updated by: willfi...@php.net Reported by:bdurand-php at ssji dot net Summary:Add DateTime::__toString() -Status: Wont fix +Status: Re-Opened Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant Assigned To:willfitch Block user comment: N Private report: N New Comment: I have reopened this as I've introduced an RFC here: https://wiki.php.net/rfc/datetime_tostring. Previous Comments: [2012-08-27 17:50:28] willfi...@php.net 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. [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. 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=62911 -- Edit this bug report at https://bugs.php.net/bug.php?id=62911&edit=1
Bug #62593 [Opn->Asn]: Emulate prepares behave strangely with PARAM_BOOL
Edit report at https://bugs.php.net/bug.php?id=62593&edit=1
ID: 62593
Updated by: willfi...@php.net
Reported by:mascione at sviluppo dot toscana dot it
Summary:Emulate prepares behave strangely with PARAM_BOOL
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu 10.04
PHP Version:5.3.14
-Assigned To:
+Assigned To:willfitch
Block user comment: N
Private report: N
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 #62593 [Asn->Ver]: Emulate prepares behave strangely with PARAM_BOOL
Edit report at https://bugs.php.net/bug.php?id=62593&edit=1
ID: 62593
Updated by: willfi...@php.net
Reported by:mascione at sviluppo dot toscana dot it
Summary:Emulate prepares behave strangely with PARAM_BOOL
-Status: Assigned
+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
Previous Comments:
[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 #62479 [Opn->Ver]: PDO-psql cannot connect if password contains spaces
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1 ID: 62479 Updated by: willfi...@php.net Reported by:brice at bmaron dot net Summary:PDO-psql cannot connect if password contains spaces -Status: Open +Status: Verified Type: Bug Package:PDO related Operating System: Linux- Debian Stable PHP Version:5.3.14 -Assigned To: +Assigned To:willfitch Block user comment: N Private report: N 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 #62593 [Ver]: Emulate prepares behave strangely with PARAM_BOOL
Edit report at https://bugs.php.net/bug.php?id=62593&edit=1
ID: 62593
Updated 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:
Pull request for this fix:
https://github.com/php/php-src/pull/198
Previous Comments:
[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 #62479 [Ver]: PDO-psql cannot connect if password contains spaces
Edit report at https://bugs.php.net/bug.php?id=62479&edit=1 ID: 62479 Updated 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: Pull request for this bug has been submitted at: https://github.com/php/php- src/pull/199. Previous Comments: [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 [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 #63124 [Opn->Nab]: PDO::ATTR_ORACLE_NULLS not respected
Edit report at https://bugs.php.net/bug.php?id=63124&edit=1
ID: 63124
Updated by: willfi...@php.net
Reported by:bugzilla at lourdas dot name
Summary:PDO::ATTR_ORACLE_NULLS not respected
-Status: Open
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Gentoo Linux
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
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
Please note - it's much easier for us to address issues with examples in simple
PHP code. It should not be assumed that those addressing the reported bugs will
be
familiar with the vast number of frameworks out there. That said, the
ATTR_ORACLE_NULLS attribute, IIRC, is on read. On write, there are dependencies
such as whether emulation is on. Take the following example:
$dsn = 'mysql:host=localhost;dbname=test;';
$pdo = new PDO($dsn);
$pdo->setAttribute(PDO::ATTR_ORACLE_NULLS, PDO::NULL_EMPTY_STRING);
$sql = 'INSERT INTO blah (id, name) VALUES (:id, :name)';
$query = $pdo->prepare($sql);
$query->bindValue('id', '1');
$query->bindValue('name', '');
$query->execute();
$sql = 'SELECT * FROM blah';
$result = $pdo->query($sql);
foreach ($result as $row)
{
var_dump($row);
}
On insert, this is the row that gets generated:
mysql> select * from blah;
+--+--+
| id | name |
+--+--+
|1 | |
+--+--+
1 row in set (0.00 sec)
You can see the value of the "name" column is actually an empty string (console
mysql would show NULL if applicable).
However, on the result set returned, the empty strings *are* indeed converted
as
requested:
array(4) {
["id"]=>
string(1) "1"
[0]=>
string(1) "1"
["name"]=>
NULL
[1]=>
NULL
}
It is up to the individual drivers to implement this functionality on write
(again, keeping emulation in mind). So, this could either be considered a
documentation issue (assuming PDO wants this functionality *only* on read), or
a
feature request for the MySQL PDO driver.
Previous Comments:
[2012-09-20 19:05:01] bugzilla at lourdas dot name
Description:
I use the latest stable version of the Yii PHP framework (v.1.1.12). I also use
the MySQL PDO driver to create a new model. The data model is taken from a HTML
form. For empty values, I get an empty string during POST. Some of the empty
values are meant to be used as foreign keys to a master table. The
corresponding MySQL database columns are nullable, so they can either have NULL
or the id of the referencing table (master). I have set the nullConversion
property of the CDbConnection class (see
http://www.yiiframework.com/doc/api/1.1/CDbConnection) which correspondingly
sets the PDO::ATTR_ORACLE_NULLS property as needed in order to convert these
empty string values to NULL before saving the model. I use the
PDO::NULL_EMPTY_STRING value in nullConversion property to do this, however, no
matter which PDO::ATTR_ORACLE_NULLS value I use, the result is always the same.
The empty strings are not converted to NULLs, so the row insertion in MySQL
fails because of foreign key constraint violation. Not to mention that if I run
the same query from the mysql client with the corresponding empty string
database columns converted to NULL, the insertion works fine. I have already
reported this as a bug to the Yii repository
(https://github.com/yiisoft/yii/issues/1442), however one of the core
developers explains that the framework simply sets the value of this PDO
property, so if the code does not work, this is a PDO bug, that's why I'm
opening this bug.
Test script:
---
In Yii's main configuration file:
'db'=>array( // this is an instance of the CDbConnection class
'connectionString' => 'mysql:host=localhost;dbname=mydb',
'emulatePrepare' => true,
'username' => 'myuser',
'password' => 'mypass',
'charset' => 'utf8',
'enableProfiling' => true,
'enableParamLogging' => true,
'nullConversion' => PDO::NULL_EMPTY_STRING,
),
and in the controller class:
if (isset($_POST['Visitors'])) { // get values from form
$visitor->attributes = $_POST['Visitors'];
$visitor->date_registered = new CDbExpression('CURDATE()');
if ($visitor->save()) // save the database model, instance of
CActiveRecord
Yii::app()->user->setFlash('userCreated', 'You have
successfully joined.');
else {
Yii::app()->user->setFlash('userCreated', 'There was a problem
creating your user account.');
}
}
Expected result:
Since some database columns are nullable, the empty strin
Bug #61754 [Opn]: pdo_pgsql fails on make
Edit report at https://bugs.php.net/bug.php?id=61754&edit=1 ID: 61754 Updated by: willfi...@php.net Reported by:gencer at gencgiyen dot com Summary:pdo_pgsql fails on make Status: Open Type: Bug Package:PDO related Operating System: CentOS 5.8 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: This looks like an environment-specific issue. pdo_pgsql.c requires pdo/php_pdo.h, but it currently can't find it in the include path. Were you able to resolve this or is this still an issue? Previous Comments: [2012-04-17 11:14:06] gencer at gencgiyen dot com I think the correct package is PDO instead of PostgreSQL ? [2012-04-17 11:00:32] gencer at gencgiyen dot com Description: When i tried to build/make my PHP with --with-pdo-pgsql=DIR command, it fails on when the make came to the pgsql. /bin/sh /installers/php/php-5.4.0/libtool --silent --preserve-dup-deps --mode=compile gcc -I/gencer/php/php-5.4.0/ext -Iext/pdo_pgsql/ -I/installers/php/php-5.4.0/ext/pdo_pgsql/ -DPHP_ATOM_INC -I/installers/php/php-5.4.0/include -I/installers/php/php-5.4.0/main -I/installers/php/php-5.4.0 -I/installers/php/php-5.4.0/ext/date/lib -I/installers/php/php-5.4.0/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/usr/include/imap -I/installers/php/php-5.4.0/ext/mbstring/oniguruma -I/installers/php/php-5.4.0/ext/mbstring/libmbfl -I/installers/php/php-5.4.0/ext/mbstring/libmbfl/mbfl -I/usr/pgsql-9.1/include -I/installers/php/php-5.4.0/ext/sqlite3/libsqlite -I/installers/php/php-5.4.0/TSRM -I/installers/php/php-5.4.0/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c -o ext/pdo_pgsql/pdo_pgsql.lo /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:28:25: error: pdo/php_pdo.h: No such file or directory /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:29:32: error: pdo/php_pdo_driver.h: No such file or directory In file included from /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:31: /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:84: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âpdo_pgsql_driverâ /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:86: error: expected â)â before â*â token /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:95: error: âPDO_ATTR_DRIVER_SPECIFICâ undeclared here (not in a function) /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:99: error: expected specifier-qualifier-list before âpdo_dbh_tâ /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:113: error: expected â)â before â*â token /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c: In function âzm_startup_pdo_pgsqlâ: /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: âpdo_pgsql_driverâ undeclared (first use in this function) /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: (Each undeclared identifier is reported only once /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: for each function it appears in.) /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c: In function âzm_shutdown_pdo_pgsqlâ: /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:104: error: âpdo_pgsql_driverâ undeclared (first use in this function) make: *** [ext/pdo_pgsql/pdo_pgsql.lo] Error 1 Test script: --- cd php-5.4.0 './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-pcre-regex' '--with-zlib' '--with-layout=GNU' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-sockets' '--with-kerberos' '--enable-ucd-snmp-hack' '--enable-shmop' '--enable-calendar' '--with-libxml-dir=/usr' '--enable-libxml' '--with-xmlrpc' '--enable-xml' '--with-system-tzdata' '--with-mhash' '--with-mysql' '--with-gd' '--enable-dom' '--disable-dba' '--without-unixODBC' '--enable-p
Bug #61754 [Opn->NoF]: pdo_pgsql fails on make
Edit report at https://bugs.php.net/bug.php?id=61754&edit=1 ID: 61754 Updated by: willfi...@php.net Reported by:gencer at gencgiyen dot com Summary:pdo_pgsql fails on make -Status: Open +Status: No Feedback Type: Bug Package:PDO related Operating System: CentOS 5.8 x86_64 PHP Version:5.4.0 Block user comment: N Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. Previous Comments: [2012-09-21 14:33:31] willfi...@php.net This looks like an environment-specific issue. pdo_pgsql.c requires pdo/php_pdo.h, but it currently can't find it in the include path. Were you able to resolve this or is this still an issue? [2012-04-17 11:14:06] gencer at gencgiyen dot com I think the correct package is PDO instead of PostgreSQL ? [2012-04-17 11:00:32] gencer at gencgiyen dot com Description: When i tried to build/make my PHP with --with-pdo-pgsql=DIR command, it fails on when the make came to the pgsql. /bin/sh /installers/php/php-5.4.0/libtool --silent --preserve-dup-deps --mode=compile gcc -I/gencer/php/php-5.4.0/ext -Iext/pdo_pgsql/ -I/installers/php/php-5.4.0/ext/pdo_pgsql/ -DPHP_ATOM_INC -I/installers/php/php-5.4.0/include -I/installers/php/php-5.4.0/main -I/installers/php/php-5.4.0 -I/installers/php/php-5.4.0/ext/date/lib -I/installers/php/php-5.4.0/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/freetype2 -I/usr/include/imap -I/installers/php/php-5.4.0/ext/mbstring/oniguruma -I/installers/php/php-5.4.0/ext/mbstring/libmbfl -I/installers/php/php-5.4.0/ext/mbstring/libmbfl/mbfl -I/usr/pgsql-9.1/include -I/installers/php/php-5.4.0/ext/sqlite3/libsqlite -I/installers/php/php-5.4.0/TSRM -I/installers/php/php-5.4.0/Zend -I/usr/include -g -O2 -fvisibility=hidden -c /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c -o ext/pdo_pgsql/pdo_pgsql.lo /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:28:25: error: pdo/php_pdo.h: No such file or directory /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:29:32: error: pdo/php_pdo_driver.h: No such file or directory In file included from /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:31: /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:84: error: expected â=â, â,â, â;â, âasmâ or â__attribute__â before âpdo_pgsql_driverâ /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:86: error: expected â)â before â*â token /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:95: error: âPDO_ATTR_DRIVER_SPECIFICâ undeclared here (not in a function) /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:99: error: expected specifier-qualifier-list before âpdo_dbh_tâ /installers/php/php-5.4.0/ext/pdo_pgsql/php_pdo_pgsql_int.h:113: error: expected â)â before â*â token /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c: In function âzm_startup_pdo_pgsqlâ: /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: âpdo_pgsql_driverâ undeclared (first use in this function) /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: (Each undeclared identifier is reported only once /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:95: error: for each function it appears in.) /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c: In function âzm_shutdown_pdo_pgsqlâ: /installers/php/php-5.4.0/ext/pdo_pgsql/pdo_pgsql.c:104: error: âpdo_pgsql_driverâ undeclared (first use in this function) make: *** [ext/pdo_pgsql/pdo_pgsql.lo] Error 1 Test script: --- cd php-5.4.0 './configure' '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-libdir=lib64' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic' '--disable-rpath' '--without-pear' '--with-bz2' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-xpm-dir=/usr' '--enable-gd-native-ttf' '--with-t1lib=/usr' '--without-gdbm' '--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=
Bug #63642 [Opn->Asn]: No "out of memory" error during ->fetchAll() from PostgreSQL
Edit report at https://bugs.php.net/bug.php?id=63642&edit=1
ID: 63642
Updated by: willfi...@php.net
Reported by:amex at bucksvsbytes dot com
Summary:No "out of memory" error during ->fetchAll() from
PostgreSQL
-Status: Open
+Status: Assigned
Type: Bug
Package:PDO related
Operating System: Ubuntu
PHP Version:5.3.19
-Assigned To:
+Assigned To:willfitch
Block user comment: N
Private report: N
Previous Comments:
[2012-12-18 21:17:38] willfi...@php.net
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?
[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
Req #62911 [ReO->Wfx]: Add DateTime::__toString()
Edit report at https://bugs.php.net/bug.php?id=62911&edit=1 ID: 62911 Updated by: willfi...@php.net Reported by:bdurand-php at ssji dot net Summary:Add DateTime::__toString() -Status: Re-Opened +Status: Wont fix Type: Feature/Change Request Package:Date/time related PHP Version:Irrelevant Assigned To:willfitch Block user comment: N Private report: N Previous Comments: [2012-09-01 10:18:12] willfi...@php.net I have reopened this as I've introduced an RFC here: https://wiki.php.net/rfc/datetime_tostring. [2012-08-27 17:50:28] willfi...@php.net 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. [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. 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=62911 -- Edit this bug report at https://bugs.php.net/bug.php?id=62911&edit=1
Bug #62571 [Opn->Asn]: Postgres PDO connections fail after SIGCHLD called
Edit report at https://bugs.php.net/bug.php?id=62571&edit=1 ID: 62571 Updated by: willfi...@php.net Reported by:spiros_ioannou at yahoo dot gr Summary:Postgres PDO connections fail after SIGCHLD called -Status: Open +Status: Assigned Type: Bug Package:PDO related Operating System: Linux PHP Version:5.3.14 -Assigned To: +Assigned To:willfitch Block user comment: N Private report: N New Comment: Can you provide a test script for your issue? Previous Comments: [2012-07-21 11:46:39] spiros_ioannou at yahoo dot gr When using persistent connections, even if reopening a new connection *after* forking, the connection fails. The only way to have DB connections is to reopen them after forking, with PDO::ATTR_PERSISTENT => false [2012-07-16 00:12:14] spiros_ioannou at yahoo dot gr I revoke the statement of SIGCHLD, it happens even without the handler in some situations, the behaviour seems erratic. Perhaps the database connection is shared with the children, and when the child dies the db variable the connection is closed. I tried closing the DB connection first thing on the child but with no results, the error still appears when the child dies. [2012-07-15 23:27:50] spiros_ioannou at yahoo dot gr Description: When using pcntl_fork to fork children, and *only* the parent uses the Postgres PDO database connection, the connection becomes unusable after the first child exits and the signal handler is called. If SIGCHLD signal handler is omitted PDO works normally for parent. Tested with and without persistent connections. Possible relevant bugs: 48447, 45797 Actual result: -- PHP Warning: PDOStatement::execute(): SQLSTATE[HY000]: General error: 7 server closed the connection unexpectedly This probably means the server terminated abnormally -- Edit this bug report at https://bugs.php.net/bug.php?id=62571&edit=1
Bug #63719 [Opn->Fbk]: mail function becomes slow until apache restart
Edit report at https://bugs.php.net/bug.php?id=63719&edit=1 ID: 63719 Updated by: willfi...@php.net Reported by:skunk at ipfrom dot com Summary:mail function becomes slow until apache restart -Status: Open +Status: Feedback Type: Bug Package:Mail related Operating System: gentoo linux PHP Version:5.3.19 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. You need to provide a sample script that's causing the issue. This sounds like an environment specific problem. Previous Comments: [2012-12-07 13:38:20] skunk at ipfrom dot com i forgot to say the sendmail command works fine and even executing from the command line a script containing the mail() function is practically instantaneous, it happens only if apache (2.2.23) executes the script. [2012-12-07 13:12:58] skunk at ipfrom dot com Description: i'm seeing this on more than one production servers: after some days of uptime the mail() function starts to take about a minute to execute and only a restart of apache (prefork) makes it fast again. one of the web servers is running roundcube which has the possibility to either use the mail() function or to connect directly to a smtp server, with the former after few days sending a mail becomes very slow while with the latest it's always fast, on a side note, when the slowness starts happening apache takes a long time to kill all processes on restart. thank you. Test script: --- sorry, i'm unable to replicate this issue because it happens on production servers with real traffic. Expected result: mail() function should exec fast Actual result: -- when mail() slows down a restart of apache is required -- Edit this bug report at https://bugs.php.net/bug.php?id=63719&edit=1
