|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #70118 PDOStatement::execute manual says "values are treated as PDO::PARAM_STR"
Submitted: 2015-07-23 14:53 UTC Modified: 2017-10-24 08:31 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: chealer at gmail dot com Assigned:
Status: Re-Opened Package: PDO related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
Solve the problem:
43 + 26 = ?
Subscribe to this entry?

 [2015-07-23 14:53 UTC] chealer at gmail dot com

    An array of values with as many elements as there are bound parameters in the SQL statement being executed. All values are treated as PDO::PARAM_STR. 
From manual page:

PDO::PARAM_STR indicates string parameters. "as PDO::PARAM_STR" could read "as strings (PDO::PARAM_STR)", or simply "as strings".


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-12-18 21:01 UTC]
-Assigned To: +Assigned To: tpunt
 [2015-12-18 21:05 UTC]
Given that it's in the context of parameter binding, I think the current description is quite unambiguous. Whilst it could be changed to read "as strings (PDO::PARAM_STR)", I personally don't feel it adds any extra clarity to the sentence.
 [2015-12-18 21:05 UTC]
-Status: Assigned +Status: Closed
 [2015-12-19 16:43 UTC] chealer at gmail dot com
tpunt, why was this closed?

Note that this is not about ambiguity, nor just about clarity. The sentence is simply wrong. PDO::PARAM_STR represents an integer which I do not know, so the current form would translate to something like "All values are treated as 1234.", which is at best the opposite of what the sentence should claim.
 [2015-12-19 18:00 UTC]
PDO::PARAM_STR does not *represent* an integer. It is *represented by* an integer, but it itself represents "the SQL CHAR, VARCHAR, or other string data type"[1]. Given the aforementioned, and that the default binding type is PDO::PARAM_STR, I still don't see the sentence as being incorrect. If anything, I'd say it is more technically accurate than mentioning "string", since we're not actually talking about strings in PHP, but rather strings at the database level (like PDO::PARAM_NULL representing the SQL NULL data type, rather than PHP's null).

 [2015-12-24 20:27 UTC] chealer at gmail dot com
tpunt: technically, PDO::PARAM_STR *is* an integer.
There are strings in systems other than PHP, so the suggestion is valid, but feel free to be more specific.

In any case, please explain why this was closed.
 [2015-12-25 15:26 UTC]
-Status: Closed +Status: Not a bug -Assigned To: tpunt +Assigned To:
 [2015-12-25 18:02 UTC]
We are not talking about what PDO::PARAM_STR is after it has been evaluated. We are talking about what it *represents* ("the SQL CHAR, VARCHAR, or other string data type"). I still think that this is therefore not a documentation problem.

If, however, you still disagree with me, then I will reopen this report and let another contributor review it.

 [2015-12-26 21:03 UTC] chealer at gmail dot com
I disagree. The sentence claims "All values are treated as PDO::PARAM_STR." Since PDO::PARAM_STR is an integer, this needs to be valid if PDO::PARAM_STR is replaced by an integer. Just like, if I claim that integers must be smaller than PHP_INT_MAX, it must be correct that integer must be smaller than 2147483647 (or another integer).

Whether or not you consider this issue as a bug, please do reopen. The current situation is definitely suboptimal.
 [2015-12-26 22:23 UTC]
-Status: Not a bug +Status: Re-Opened
 [2015-12-26 22:37 UTC]
Your stance is that constants should be replaceable by the integer value they're represented by, and the sentence should still make sense.

By this notion, numerous other places in the manual are also incorrect. Take, for example, the following sentence from the error reporting page[1]: "Enabling E_NOTICE during development has some benefits." The constant E_NOTICE is represented by the integer value 8, and so the sentence - from your stance - is nonsensical because you're saying that its equivalent to the following sentence: "Enabling 8 during development has some benefits."

This is not true. The constant E_NOTICE has meaning to the developer because it *represents* something. Replacing it with the value it is *represented by* will of course not make any sense, but it shouldn't need to either. We don't care what value it is represented by, only the meaning the constant has.

Anyway, I've reopened this at your request, but I still disagree with your opinion.


 [2015-12-26 23:04 UTC] chealer at gmail dot com
Thank you Tom.

I understand without effort the example you give. But I maintain that it is also technically incorrect. Instead of:
"Enabling E_NOTICE during development has some benefits."
it would be more clear to state, for example:
"Enabling notices (with E_NOTICE) during development has some benefits."
 [2017-01-28 17:24 UTC]
-Package: Documentation problem +Package: PDO Core
 [2017-10-24 08:31 UTC]
-Package: PDO Core +Package: PDO related
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat May 18 23:01:31 2024 UTC