Re: [VOTE] Add PDO function: mysqlGetWarningCount

From: Date: Wed, 07 Jul 2021 21:15:29 +0000
Subject: Re: [VOTE] Add PDO function: mysqlGetWarningCount
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-115358@lists.php.net to get a copy of this message
On Jul 6, 2021, at 08:34, Daniel Beardsley <dbeardsl@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.

« previous php.internals (#115358) next »