[VOTE] Add PDO function: mysqlGetWarningCount

  115331
July 6, 2021 15:34 dbeardsl@gmail.com (Daniel Beardsley)
My previous email had an ambiguous subject line. My apologies.

I've moved my RFC to the voting phase.

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 pull request (with tests) is here: https://github.com/php/php-src/pull/6677 Thanks for your time! Daniel
  115358
July 7, 2021 21:15 dusk@woofle.net (Dusk)
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.
  115584
July 26, 2021 12:48 petercowburn@gmail.com (Peter Cowburn)
> > On Jul 6, 2021, at 08:34, Daniel Beardsley <dbeardsl@gmail.com> wrote:
Voting will be open till 2020-07-21
>
This date has passed, yet the vote is still ongoing. Daniel, could you please close the vote and do the usual follow up tasks? If Daniel is unavailable, what is the process for *someone else* doing those things?
  115588
July 26, 2021 22:33 ryan.jentzsch@gmail.com (Ryan Jentzsch)
Is there a process in place for RFCs that address bugs in bugs.php.net if
they have a passing vote to mark the bug as "FIXED in version xx.xx.xx" or
if the RFC doesn't pass mark the bug as "WONTFIX"?

On Mon, Jul 26, 2021 at 6:49 AM Peter Cowburn <petercowburn@gmail.com>
wrote:

> > > > On Jul 6, 2021, at 08:34, Daniel Beardsley <dbeardsl@gmail.com> wrote: > > > > Voting will be open till 2020-07-21 > > > > This date has passed, yet the vote is still ongoing. > Daniel, could you please close the vote and do the usual follow up tasks? > If Daniel is unavailable, what is the process for *someone else* doing > those things? >
  115589
July 26, 2021 23:16 kalle@php.net (Kalle Sommer Nielsen)
Den man. 26. jul. 2021 kl. 15.49 skrev Peter Cowburn <petercowburn@gmail.com>:
> This date has passed, yet the vote is still ongoing. > Daniel, could you please close the vote and do the usual follow up tasks? > If Daniel is unavailable, what is the process for *someone else* doing > those things?
I took the liberty to close the vote and moved the RFC to the Withdrawn section given its supposedly abandoned status -- regards, Kalle Sommer Nielsen kalle@php.net