Fix prepared statements + 0 rows + fields segfault

[skipkayhil]

Ref rails/rails#55745

require "mysql2"

c = ::Mysql2::Client.new(database: "activerecord_unittest", username: "rails")
ps = c.prepare("SELECT * FROM products WHERE 1=0")
r = ps.execute
puts r.fields

This script (connection configured for the Rails repo, but unimportant) segfaults consistently on 0.5.7 but runs fine on 0.5.6.

Reverting #1399 with no other changes fixes the segfault. I'm not sure if this is fully correct, but it doesn't crash.

[sodabrew]

What version of MySQL or MariaDB client libraries are you using?

[skipkayhil]

What version of MySQL or MariaDB client libraries are you using?

❯ apt list --installed | rg mysql

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libmysqlclient-dev/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
libmysqlclient21/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
mysql-client-8.0/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
mysql-client-core-8.0/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
mysql-common/noble,now 5.8+1.1.0build1 all [installed,automatic]
mysql-server-8.0/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
mysql-server-core-8.0/noble-security,now 8.0.43-0ubuntu0.24.04.1 amd64 [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]
mysql-server/noble-security,now 8.0.43-0ubuntu0.24.04.1 all [installed,upgradable to: 8.0.43-0ubuntu0.24.04.2]

(also looks like my test is failing, I'll try to get that fixed)

Edit: another note - I wasn't able to reproduce on Mac (ARM), only on Ubuntu

[jeremyevans]

Sequel's tests don't segfault with 0.5.7, but there is a failure in Sequel's prepared statement tests with mysql 0.5.7 that wasn't there in previous versions: https://github.com/jeremyevans/sequel/actions/runs/18055866092/job/51385562191#step:7:81

The error occurs when executing an UPDATE prepared statement that returns 0 rows, so it does look like reverting #1399 would fix the issue (but I didn't test it).