On Jul 6, 2021, at 08:34, Daniel Beardsley <dbear...@gmail.com> wrote: > The proposal: >> Add a function that exposes the warning count of the most recent >> statement for MySQL: $pdo->mysqlGetWarningCount(). It returns an int >> straight from the MySQL driver. This fixes the open bug at: >> https://bugs.php.net/bug.php?id=51499. > > Voting will be open till 2020-07-21 > > https://wiki.php.net/rfc/pdo-mysql-get-warning-count
The proposed vote declares that that: > “Yes” means this pull request should be merged (pending code review). “No” > means we don't want PDO to expose MySQLs warning count. This seems like a false dichotomy. What response would be appropriate for "exposing the MySQL warning count in PDO is fine, but this isn't the right way to do it"? I'm not eligible to vote, but speaking for myself, I'd prefer a more generic mechanism for exposing metadata about queries -- not one that's specific to MySQL, nor one which only exposes a warning count. For example, MySQL also exposes some flags for statements where no index was used, and SQLite has functions to obtain the expanded SQL for a statement or to check if it's a read-only operation; all of these, along with the MySQL warning count, would fit nicely into a more generic PDO statement metadata API. Would it be possible to amend the voting statement to: > “Yes” means this pull request should be merged (pending code review). “No” > means **the pull request should not be merged**. without invalidating existing votes? It would be unfortunate for this vote to be interpreted as a rejection of any future PDO API which happens to include the MySQL warning count. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
