Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130628
Precedence: list
MIME-Version: 1.0
References: <CAANVRFiatY+SJdmEf56wzOvY5_9QmH7BtMB6yPzbt1xatYc_1A@mail.gmail.com>
 <CAGBsUrezVkQNtYbKENJ-emZY-ccZvEVhnjPmnL9YBofsXJmjcw@mail.gmail.com>
In-Reply-To: <CAGBsUrezVkQNtYbKENJ-emZY-ccZvEVhnjPmnL9YBofsXJmjcw@mail.gmail.com>
Date: Tue, 14 Apr 2026 14:21:48 +0200
Message-ID: <CAANVRFgDsmw2v=ue=hyJTgE57k1qEQNZ_immxjCWZY0hQv08dg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add MariaDB-specific features to
 mysqlnd and mysqli
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005ac1bd064f6aa5bf"
From: georg@mariadb.com (Georg Richter)

--0000000000005ac1bd064f6aa5bf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Kamil,

Thank you for the detailed feedback. I=E2=80=99ve updated the RFC to reflec=
t
several of your points, specifically regarding the separation of concerns.
To keep things clean, everything not directly visible to the user (metadata
caching, extended metadata, auth plugins) will be moved to separate PRs.


> Extended Metadata:
> It looks like you have some formatting issues there. I don't
> understand what this feature is, how to use it, nor how it will be
> exposed. It needs more explanation.
>
> In the table, you mention that it doesn't require any user-facing
> changes, but it does. The returned structure is extended with two new
> fields from what I can see. Additionally, the PoC changes existing
> field values too.
>

Extended metadata will go to a separate PR - we only need to map
MYSQL_TYPE_LONGTYPE + json to MYSQL_TYPE_JSON. and MYSQL_TYPE_BLOB + vector
to MYSQL_TYPE_VECTOR.


>
> ----------------------------
>
> Prepared Statement Metadata Caching:
> In theory I am all for adding transparent improvements and they don't
> usually require an RFC, but in this case, I don't understand how the
> caching will be done. Are you saying the user will need to cache the
> metadata somewhere? Is the cache shared across requests? How will the
> cache be invalidated/cleaned?
>
Right this will also be implemented via PR

>
> From the implementation, it seems like the cache is only per prepared
> statement, i.e. only the first execute() call will fetch the metadata.
> If that's all it is then it can be made into a simple PR without RFC.
> But in the table you say "Avoids resending metadata for repeated
> prepares" which confuses me.
>

The caching mechanism is designed to be transparent within the mysqlnd
layer. Historically, MySQL and older MariaDB versions sent metadata during
the PREPARE phase and again for every subsequent EXECUTE.

MariaDB has optimized this: the server now only sends metadata during
EXECUTE if the table structure or definition has changed. By implementing
caching in mysqlnd, we can skip the redundant allocation and parsing of
metadata packets. This is managed internally by the driver and does not
require the user to manually clean or invalidate the cache.


> > Performance Improvements: Existing PHP functions that prepare and
> execute statements, such as mysql_execute_query() (introduced in PHP 8.2)=
,
> could be updated to use execute_direct when connected to a MariaDB server=
.
> This would allow one-time statements to bypass the extra round-trip and
> metadata fetch, providing immediate performance gains.
>
> Does this refer to caching? How does caching improve the performance
> of a one-time executed prepared statement? If that's not what it
> refers to, then what did you mean?
>

Sorry I forgot to remove this before I published it. MariaDB supports
direct execution by sending prepare and execute together - this doesn't
seem to work with php_streams.

>
> ----------------------------
>
> Progress Indication:
> I'm quite worried about this one. PHP doesn't have native asynchronous
> support yet. How do you intend for this to work when a built-in PHP
> function can be suspended and possibly interrupted completely while
> the MySQL is processing the request?
>

To clarify: this is not asynchronous in the Fiber sense. It is a
synchronous "keep-alive" mechanism. During long-running operations (like
ALTER TABLE, LOAD DATA, or complex INSERT...SELECT statements), the server
sends "progress" packets.

Currently, mysqlnd ignores these, which can lead to connection timeouts or
a lack of feedback for the user. By supporting these packets, the driver
stays active, preventing timeouts and allowing the application to provide
real-time feedback to the user or logs, ensuring the client knows the
server is still alive and working.


>
> ----------------------------
>
> PDO Considerations:
> Why is PDO out of scope? PDO is the main database extension in PHP. If
> any new feature is added, then it should probably be exposed via PDO
> first. What do you mean by "PDO_MySQL currently does not support array
> binding or bulk execution semantics"?
>

PDO is currently out of scope only to ensure a manageable and focused RFC.
Implementing these features in mysqlnd provides the necessary binary
foundation. A future "PDO Bulk RFC" can then leverage this work across all
drivers (PostgreSQL, SQLite, etc.) without needing to reinvent the
protocol-specific logic for the MySQL/MariaDB ecosystem. We are building
the engine first; the unified PDO interface can follow.

>
> ----------------------------
>
> Server capabilities:
> I don't think it's more robust to detect MariaDB server by the lack of
> CLIENT_LONG_PASSWORD than it is by the server_version. What if MySQL
> decides to remove that flag in the future? What if derived products
> don't follow the same convention?
>
> Why is it necessary to expose this information to the PHP user via
> server_capabilities and ext_server_capabilities? I can't find anywhere
> that you explain what information is presented in these properties or
> how to use it.
>

There is a fundamental difference between what a server might do (Version)
and what it can do (Capabilities). A version string is a static label.
Capability flags, however, reflect the server=E2=80=99s current build-time =
features
and runtime configuration.

Exposing ext_server_capabilities allows developers and frameworks to
implement reliable feature detection. Without these flags, a developer
cannot safely use functions without risking a fatal error or needing to
wrap every call in a try-catch block.

 ----------------------------

>
> Memory Consumption:
> Why is using generators going to use less memory? How does the new
> function use generators that it's able to provide performance
> improvements without reading all of the data from the generator
> beforehand? This needs to be clearly explained so that it can be
> explained in the PHP manual later. What is the difference between
> these two:
>
> ```
> $stmt->executemany("sd", $generator);
> $stmt->executemany("sd", iterator_to_array($generator));
> ```
>
> The performance improvement is not derived from the Generator itself, but
from the reduction of network round-trips.

- standard foreach + execute(): 1,000 rows =3D 1,000 "Send" packets + 1,000
"Response" packets.
- execute_many(): The driver pulls rows from the iterable and serializes
them into a large internal network buffer. 1,000 rows =3D 1 large Send pack=
et
+ 1 Response packet.

Regarding iterator_to_array($generator): This forces PHP to allocate memory
for every single row simultaneously. If you are importing 1 million rows,
PHP must allocate memory for 1 million arrays before the first byte is ever
sent. By using the Generator directly, we maintain O(1) memory usage,
fetching and serializing only one row at a time.



> ----------------------------
>
> mysqli_stmt::executemany implementation:
> You only mention the OO-style method in the RFC. Will the procedural
> style counterpart also be implemented?
>

yes - OO and procedural functions use the same code.

>
> The name doesn't follow mysqli naming standard. It should be called
> mysqli_stmt::execute_many. However, I wonder what made you land on
> this name instead of mysqli_stmt::bulk_execute?
>
> There should be no $types parameter IMHO. The data should either
> always be treated as text, or it should be bound using the PHP type,
> i.e. autodetected. I believe it was a mistake that bind_param() has a
> $types parameter. All it serves is to cast the data silently into the
> specified type. It has been a source of many silent bugs and a lot of
> confusion. Additionally, giving users more type choices in
> executemany() will not only create an inconsistency with bind_param(),
> but also confuse PHP users who don't know if a variable is 8, or 16,
> or 32, or 64-bit.
>

You are absolutely right=E2=80=94the name should follow the underscore conv=
ention,
so it will be execute_many. Regarding the parameter order and the $types
question, the proposed signature could be:

public mysqli_stmt::execute_many(iterable $data, ?iterable $control =3D nul=
l,
?string $types =3D null): bool
public mysqli_stmt_execute_many(mysqli_stmt $stmt, iterable $data,
?iterable $control =3D null, ?string $types =3D null): bool

By placing $control and $types at the end as optional parameters, we can
leverage PHP 8 named parameters to resolve the conflict between ease-of-use
and technical optimization.

1. The "All-Strings" Path (Implicit Autodetection)

To address your concern about autodetection: providing $types is not
mandatory. If the user simply calls $stmt->execute_many($data), the driver
will implicitly treat all scalar values as strings. Since MariaDB and MySQL
handle implicit casting efficiently, this provides the seamless "it just
works" experience you requested for the majority of use cases.

2. The "Strict-Typed" Path (Memory & Bandwidth Optimization)

While autodetection is convenient, specifying $types remains critical when
resource optimization is a factor:

- Binary Efficiency: By specifying types like i (LONG) or 1 (TINYINT), we
significantly reduce the network payload compared to sending everything as
strings (up to an 80% reduction for certain numeric columns).
- O(1) Memory Safety for Streams: Because the MariaDB bulk protocol
requires type declarations in the packet header before the data rows are
sent, the driver cannot "autodetect" binary widths from a Generator without
reading the entire stream into memory first. Providing the $types string
acts as a contract that allows for true, constant-memory streaming.

3. The "Control" Parameter and Indicators

I agree that the Indicator Enum should be moved to mysqli
(mysqli_indicator). The $control array serves three critical architectural
purposes:

- Non-Destructive Transformation: It allows developers to apply logic (like
DEFAULT or NULL overrides) without modifying the original $data array or
stream. This is vital if the data source is a read-only Generator or is
being reused elsewhere in the application.
- Security (Sensitive Data Overwrite): The $control array acts as a secure
template. A developer can pass a raw data array but use the control array
to force a status column to "active" or a last_modified_by column to a
specific ID, ensuring sensitive fields are overwritten regardless of the
input data's content.
-Flexibility: It supports both a Global Mode (one row that acts as a mask
for the entire batch) and a Streaming Mode (an iterable that advances in
parallel with the data).

This design ensures that execute_many remains simple for beginners while
providing the granular control required by high-performance implementations=
.


> Please be explicit what the failure conditions may be.
>

Like for all other functions you have to retrieve error messages via
mysqli_stmt::error/errno.


> How does get_result() work with executemany()? For example, if I
> execute SELECT ?,? with [[1,2], [3,4]] will I get that same structure
> in the result set? Is the sequence guaranteed? Is there a way to
> distinguish which row came from which input data row? What if one
> SELECT produces two rows and the other zero? Will it still be a single
> mysqli_result?
>

As mentioned in the beginning of the RFC, execute_many is used for UPSERT
(insert, replace,delete and update) operations. However it might contain a
result set, e.g. by having a RETURNING clause.


>
> How does it work with store_result() and also with unbuffered result
> sets? I assume it's all treated the same as a normal execute(),
> correct?
>

Yep

>
> How does this affect insert_id? MariaDB documentation says that only
> "the first auto-generated ID" is returned, which is contrary to what I
> expect: the last. Does the value propagate to PHP? If so, why?
>

This behavior matches the standard MySQL C API and protocol where
mysql_insert_id() returns the first ID of a multi-row insert, not the last:

MySQL [test]> truncate table t1;
Query OK, 0 rows affected (0.075 sec)

MySQL [test]> insert into t1 (name) values ('foo'),('bar'),('PHP');
Query OK, 3 rows affected (0.017 sec)
Records: 3  Duplicates: 0  Warnings: 0

MySQL [test]> select last_insert_id()\G;
*************************** 1. row ***************************
last_insert_id(): 1


>
> From what I can see, it is possible to request that MariaDB reply with
> individual result sets. Wouldn't that be better? How would that impact
> the performance?
>

If you require the IDs of every row in a bulk insert, the MariaDB RETURNING
clause should be used:

INSERT INTO t1 (name) VALUES (?) RETURNING id


> How about atomicity? If I make 3 INSERTS and the middle one fails,
> will the other two execute?
>

For transactional engines like InnoDB, atomicity is guaranteed. If a
protocol error occurs or a constraint is hit mid-batch, the server handles
the rollback, ensuring the database remains in a consistent state.


>
> Indicator enum should contain only two values: IGNORE and DEFAULT.
> Null is already a PHP data type and does not require an indicator.
> None serves no purpose (what would even happen if someone used it).
> Adding an Indicator enum will create an inconsistency with the
> existing feature set which do not support it.
> An enum should be defined by the extension in which it will be used,
> i.e. mysqli. The mysqlnd extension shuld not expose any user-facing
> APIs.
>

See my comments about new execute_many parameters (control). Even None is
used to indicate to use the original value from $data block.
NULL and mysqli_indicator::Null are indeed the same - however it is more
consistant with other drivers (e.g. ODBC and OCI) to have a Null indicator.


>
> When connected to the MySQL server, how will executemany() behave? I
> assume there will be an emulated support for it in mysqlnd, but how
> will you ensure consistency between these two implementations? Making
> the function no-op with MySQL should be out of the question.
>

When connected to a server that does not support the native bulk protocol
(such as standard MySQL), execute_many() will transition to a fallback
emulation layer. This ensures that the function remains a reliable,
portable API for developers regardless of the backend. However, there are
inherent limitations to this emulation:

- Limited Indicator Support: Since the standard MySQL COM_STMT_EXECUTE
protocol does not understand MariaDB-specific indicators, the fallback will
only support mysqli_indicator::Null (translated to a standard SQL NULL) and
mysqli_indicator::None. Indicators like DEFAULT and IGNORE are technically
impossible to implement in the fallback without complex SQL string
manipulation/rewriting, which would introduce unacceptable CPU overhead.

- Transaction Safety & Atomicity: In native MariaDB bulk mode, the entire
batch is sent as a single unit. In the fallback emulation, rows are
executed one by one. For non-transactional engines, a failure on row 500
would leave the first 499 rows committed. To maintain consistency, we
should recommend that users wrap execute_many() in an explicit transaction
when portability across MySQL and MariaDB is required.

- Performance Delta: While the fallback provides a consistent API, it does
not offer the network round-trip savings of the native protocol. Each row
in the fallback requires a separate request/response cycle, effectively
acting as a "C-speed" foreach loop.

/Georg

--=20
Georg Richter, Staff Software Engineer
Client Connectivity
MariaDB Corporation Ab

--0000000000005ac1bd064f6aa5bf
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi Kamil,<br><br>Thank you for the detail=
ed feedback. I=E2=80=99ve updated the RFC to reflect several of your points=
, specifically regarding the separation of concerns. To keep things clean, =
everything not directly visible to the user (metadata caching, extended met=
adata, auth plugins) will be moved to separate PRs.<div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">
Extended Metadata:<br>
It looks like you have some formatting issues there. I don&#39;t<br>
understand what this feature is, how to use it, nor how it will be<br>
exposed. It needs more explanation.<br>
<br>
In the table, you mention that it doesn&#39;t require any user-facing<br>
changes, but it does. The returned structure is extended with two new<br>
fields from what I can see. Additionally, the PoC changes existing<br>
field values too.<br></blockquote><div><br></div><div>Extended metadata wil=
l go to a separate PR - we only need to map MYSQL_TYPE_LONGTYPE=C2=A0+ json=
 to MYSQL_TYPE_JSON. and MYSQL_TYPE_BLOB=C2=A0+ vector to MYSQL_TYPE_VECTOR=
.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
<br>
----------------------------<br>
<br>
Prepared Statement Metadata Caching:<br>
In theory I am all for adding transparent improvements and they don&#39;t<b=
r>
usually require an RFC, but in this case, I don&#39;t understand how the<br=
>
caching will be done. Are you saying the user will need to cache the<br>
metadata somewhere? Is the cache shared across requests? How will the<br>
cache be invalidated/cleaned?<br></blockquote><div>Right this will also be =
implemented via PR</div><div></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
From the implementation, it seems like the cache is only per prepared<br>
statement, i.e. only the first execute() call will fetch the metadata.<br>
If that&#39;s all it is then it can be made into a simple PR without RFC.<b=
r>
But in the table you say &quot;Avoids resending metadata for repeated<br>
prepares&quot; which confuses me.<br></blockquote><div>=C2=A0</div><div>The=
 caching mechanism is designed to be transparent within the mysqlnd layer. =
Historically, MySQL and older MariaDB versions sent metadata during the PRE=
PARE phase and again for every subsequent EXECUTE.<br><br>MariaDB has optim=
ized this: the server now only sends metadata during EXECUTE if the table s=
tructure or definition has changed. By implementing caching in mysqlnd, we =
can skip the redundant allocation and parsing of metadata packets. This is =
managed internally by the driver and does not require the user to manually =
clean or invalidate the cache.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><br>
&gt; Performance Improvements: Existing PHP functions that prepare and exec=
ute statements, such as mysql_execute_query() (introduced in PHP 8.2), coul=
d be updated to use execute_direct when connected to a MariaDB server. This=
 would allow one-time statements to bypass the extra round-trip and metadat=
a fetch, providing immediate performance gains.<br>
<br>
Does this refer to caching? How does caching improve the performance<br>
of a one-time executed prepared statement? If that&#39;s not what it<br>
refers to, then what did you mean?<br></blockquote><div><br></div><div>Sorr=
y I forgot to remove this before I published it. MariaDB supports direct ex=
ecution by sending prepare and execute together - this doesn&#39;t seem to =
work with php_streams.=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
<br>
----------------------------<br>
<br>
Progress Indication:<br>
I&#39;m quite worried about this one. PHP doesn&#39;t have native asynchron=
ous<br>
support yet. How do you intend for this to work when a built-in PHP<br>
function can be suspended and possibly interrupted completely while<br>
the MySQL is processing the request?<br></blockquote><div><br></div><div>To=
 clarify: this is not asynchronous in the Fiber sense. It is a synchronous =
&quot;keep-alive&quot; mechanism. During long-running operations (like ALTE=
R TABLE, LOAD DATA, or complex INSERT...SELECT statements), the server send=
s &quot;progress&quot; packets.<br><br>Currently, mysqlnd ignores these, wh=
ich can lead to connection timeouts or a lack of feedback for the user. By =
supporting these packets, the driver stays active, preventing timeouts and =
allowing the application to provide real-time feedback to the user or logs,=
 ensuring the client knows the server is still alive and working.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
----------------------------<br>
<br>
PDO Considerations:<br>
Why is PDO out of scope? PDO is the main database extension in PHP. If<br>
any new feature is added, then it should probably be exposed via PDO<br>
first. What do you mean by &quot;PDO_MySQL currently does not support array=
<br>
binding or bulk execution semantics&quot;?<br></blockquote><div><br></div><=
div>PDO is currently out of scope only to ensure a manageable and focused R=
FC. Implementing these features in mysqlnd provides the necessary binary fo=
undation. A future &quot;PDO Bulk RFC&quot; can then leverage this work acr=
oss all drivers (PostgreSQL, SQLite, etc.) without needing to reinvent the =
protocol-specific logic for the MySQL/MariaDB ecosystem. We are building th=
e engine first; the unified PDO interface can follow.=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">
<br>
----------------------------<br>
<br>
Server capabilities:<br>
I don&#39;t think it&#39;s more robust to detect MariaDB server by the lack=
 of<br>
CLIENT_LONG_PASSWORD than it is by the server_version. What if MySQL<br>
decides to remove that flag in the future? What if derived products<br>
don&#39;t follow the same convention?<br>
<br>
Why is it necessary to expose this information to the PHP user via<br>
server_capabilities and ext_server_capabilities? I can&#39;t find anywhere<=
br>
that you explain what information is presented in these properties or<br>
how to use it.<br></blockquote><div><br></div><div>There is a fundamental d=
ifference between what a server might do (Version) and what it can do (Capa=
bilities). A version string is a static label. Capability flags, however, r=
eflect the server=E2=80=99s current build-time features and runtime configu=
ration.<br><br>Exposing ext_server_capabilities allows developers and frame=
works to implement reliable feature detection. Without these flags, a devel=
oper cannot safely use functions without risking a fatal error or needing t=
o wrap every call in a try-catch block.<br><br></div><div>=C2=A0-----------=
-----------------</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Memory Consumption:<br>
Why is using generators going to use less memory? How does the new<br>
function use generators that it&#39;s able to provide performance<br>
improvements without reading all of the data from the generator<br>
beforehand? This needs to be clearly explained so that it can be<br>
explained in the PHP manual later. What is the difference between<br>
these two:<br>
<br>
```<br>
$stmt-&gt;executemany(&quot;sd&quot;, $generator);<br>
$stmt-&gt;executemany(&quot;sd&quot;, iterator_to_array($generator));<br>
```<br>
<br></blockquote><div>The performance improvement is not derived from the G=
enerator itself, but from the reduction of network round-trips.<br><br>- st=
andard foreach + execute(): 1,000 rows =3D 1,000 &quot;Send&quot; packets +=
 1,000 &quot;Response&quot; packets.<br>- execute_many(): The driver pulls =
rows from the iterable and serializes them into a large internal network bu=
ffer. 1,000 rows =3D 1 large Send packet + 1 Response packet.<br><br>Regard=
ing iterator_to_array($generator): This forces PHP to allocate memory for e=
very single row simultaneously. If you are importing 1 million rows, PHP mu=
st allocate memory for 1 million arrays before the first byte is ever sent.=
 By using the Generator directly, we maintain O(1) memory usage, fetching a=
nd serializing only one row at a time.<br><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex">
----------------------------<br>
<br>
mysqli_stmt::executemany implementation:<br>
You only mention the OO-style method in the RFC. Will the procedural<br>
style counterpart also be implemented?<br></blockquote><div><br></div><div>=
yes - OO and procedural functions use the same code.=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex">
<br>
The name doesn&#39;t follow mysqli naming standard. It should be called<br>
mysqli_stmt::execute_many. However, I wonder what made you land on<br>
this name instead of mysqli_stmt::bulk_execute?<br>
<br>
There should be no $types parameter IMHO. The data should either<br>
always be treated as text, or it should be bound using the PHP type,<br>
i.e. autodetected. I believe it was a mistake that bind_param() has a<br>
$types parameter. All it serves is to cast the data silently into the<br>
specified type. It has been a source of many silent bugs and a lot of<br>
confusion. Additionally, giving users more type choices in<br>
executemany() will not only create an inconsistency with bind_param(),<br>
but also confuse PHP users who don&#39;t know if a variable is 8, or 16,<br=
>
or 32, or 64-bit.<br></blockquote><div><br></div><div>You are absolutely ri=
ght=E2=80=94the name should follow the underscore convention, so it will be=
 execute_many. Regarding the parameter order and the $types question, the p=
roposed signature could be:<br><br>public mysqli_stmt::execute_many(iterabl=
e $data, ?iterable $control =3D null, ?string $types =3D null): bool<br>pub=
lic mysqli_stmt_execute_many(mysqli_stmt $stmt, iterable $data, ?iterable $=
control =3D null, ?string $types =3D null): bool<br><br>By placing $control=
 and $types at the end as optional parameters, we can leverage PHP 8 named =
parameters to resolve the conflict between ease-of-use and technical optimi=
zation.<br><br>1. The &quot;All-Strings&quot; Path (Implicit Autodetection)=
<br><br>To address your concern about autodetection: providing $types is no=
t mandatory. If the user simply calls $stmt-&gt;execute_many($data), the dr=
iver will implicitly treat all scalar values as strings. Since MariaDB and =
MySQL handle implicit casting efficiently, this provides the seamless &quot=
;it just works&quot; experience you requested for the majority of use cases=
.<br><br>2. The &quot;Strict-Typed&quot; Path (Memory &amp; Bandwidth Optim=
ization)<br><br>While autodetection is convenient, specifying $types remain=
s critical when resource optimization is a factor:<br><br>- Binary Efficien=
cy: By specifying types like i (LONG) or 1 (TINYINT), we significantly redu=
ce the network payload compared to sending everything as strings (up to an =
80% reduction for certain numeric columns).<br>- O(1) Memory Safety for Str=
eams: Because the MariaDB bulk protocol requires type declarations in the p=
acket header before the data rows are sent, the driver cannot &quot;autodet=
ect&quot; binary widths from a Generator without reading the entire stream =
into memory first. Providing the $types string acts as a contract that allo=
ws for true, constant-memory streaming.<br><br>3. The &quot;Control&quot; P=
arameter and Indicators<br><br>I agree that the Indicator Enum should be mo=
ved to mysqli (mysqli_indicator). The $control array serves three critical =
architectural purposes:<br><br>- Non-Destructive Transformation: It allows =
developers to apply logic (like DEFAULT or NULL overrides) without modifyin=
g the original $data array or stream. This is vital if the data source is a=
 read-only Generator or is being reused elsewhere in the application.<br>- =
Security (Sensitive Data Overwrite): The $control array acts as a secure te=
mplate. A developer can pass a raw data array but use the control array to =
force a status column to &quot;active&quot; or a last_modified_by column to=
 a specific ID, ensuring sensitive fields are overwritten regardless of the=
 input data&#39;s content.<br>-Flexibility: It supports both a Global Mode =
(one row that acts as a mask for the entire batch) and a Streaming Mode (an=
 iterable that advances in parallel with the data).<br><br>This design ensu=
res that execute_many remains simple for beginners while providing the gran=
ular control required by high-performance implementations.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Please be explicit what the failure conditions may be.<br></blockquote><div=
><br></div><div>Like for all other functions you have to retrieve error mes=
sages via mysqli_stmt::error/errno.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
How does get_result() work with executemany()? For example, if I<br>
execute SELECT ?,? with [[1,2], [3,4]] will I get that same structure<br>
in the result set? Is the sequence guaranteed? Is there a way to<br>
distinguish which row came from which input data row? What if one<br>
SELECT produces two rows and the other zero? Will it still be a single<br>
mysqli_result?<br></blockquote><div><br></div><div>As mentioned in the begi=
nning of the RFC, execute_many is used for UPSERT (insert, replace,delete a=
nd update) operations. However it might contain a result set, e.g. by havin=
g a RETURNING clause.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
<br>
How does it work with store_result() and also with unbuffered result<br>
sets? I assume it&#39;s all treated the same as a normal execute(),<br>
correct?<br></blockquote><div><br></div><div>Yep=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
<br>
How does this affect insert_id? MariaDB documentation says that only<br>
&quot;the first auto-generated ID&quot; is returned, which is contrary to w=
hat I<br>
expect: the last. Does the value propagate to PHP? If so, why?<br></blockqu=
ote><div><br></div><div>This behavior matches the standard MySQL C API and =
protocol where mysql_insert_id() returns the first ID of a multi-row insert=
, not the last:</div><div><br></div><div></div><div>MySQL [test]&gt; trunca=
te table t1;<br>Query OK, 0 rows affected (0.075 sec)<br><br>MySQL [test]&g=
t; insert into t1 (name) values (&#39;foo&#39;),(&#39;bar&#39;),(&#39;PHP&#=
39;);<br>Query OK, 3 rows affected (0.017 sec)<br>Records: 3 =C2=A0Duplicat=
es: 0 =C2=A0Warnings: 0<br><br>MySQL [test]&gt; select last_insert_id()\G;<=
br>*************************** 1. row ***************************<br>last_i=
nsert_id(): 1<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">
<br>
From what I can see, it is possible to request that MariaDB reply with<br>
individual result sets. Wouldn&#39;t that be better? How would that impact<=
br>
the performance?<br></blockquote><div><br></div><div>If you require the IDs=
 of every row in a bulk insert, the MariaDB RETURNING clause should be used=
:</div><div><br></div><div>INSERT INTO t1 (name) VALUES (?) RETURNING id</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
How about atomicity? If I make 3 INSERTS and the middle one fails,<br>
will the other two execute?<br></blockquote><div><br></div><div>For transac=
tional engines like InnoDB, atomicity is guaranteed. If a protocol error oc=
curs or a constraint is hit mid-batch, the server handles the rollback, ens=
uring the database remains in a consistent state.</div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Indicator enum should contain only two values: IGNORE and DEFAULT.<br>
Null is already a PHP data type and does not require an indicator.<br>
None serves no purpose (what would even happen if someone used it).<br>
Adding an Indicator enum will create an inconsistency with the<br>
existing feature set which do not support it.<br>
An enum should be defined by the extension in which it will be used,<br>
i.e. mysqli. The mysqlnd extension shuld not expose any user-facing<br>
APIs.<br></blockquote><div><br></div><div>See my comments about new execute=
_many parameters (control). Even None is used to indicate to use the origin=
al value from $data block.</div><div>NULL and mysqli_indicator::Null are in=
deed the same - however it is more consistant with other drivers (e.g. ODBC=
 and OCI) to have a Null indicator.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
When connected to the MySQL server, how will executemany() behave? I<br>
assume there will be an emulated support for it in mysqlnd, but how<br>
will you ensure consistency between these two implementations? Making<br>
the function no-op with MySQL should be out of the question.<br></blockquot=
e><div><br></div><div>When connected to a server that does not support the =
native bulk protocol (such as standard MySQL), execute_many() will transiti=
on to a fallback emulation layer. This ensures that the function remains a =
reliable, portable API for developers regardless of the backend. However, t=
here are inherent limitations to this emulation:<br><br>- Limited Indicator=
 Support: Since the standard MySQL COM_STMT_EXECUTE protocol does not under=
stand MariaDB-specific indicators, the fallback will only support mysqli_in=
dicator::Null (translated to a standard SQL NULL) and mysqli_indicator::Non=
e. Indicators like DEFAULT and IGNORE are technically impossible to impleme=
nt in the fallback without complex SQL string manipulation/rewriting, which=
 would introduce unacceptable CPU overhead.<br><br>- Transaction Safety &am=
p; Atomicity: In native MariaDB bulk mode, the entire batch is sent as a si=
ngle unit. In the fallback emulation, rows are executed one by one. For non=
-transactional engines, a failure on row 500 would leave the first 499 rows=
 committed. To maintain consistency, we should recommend that users wrap ex=
ecute_many() in an explicit transaction when portability across MySQL and M=
ariaDB is required.<br><br>- Performance Delta: While the fallback provides=
 a consistent API, it does not offer the network round-trip savings of the =
native protocol. Each row in the fallback requires a separate request/respo=
nse cycle, effectively acting as a &quot;C-speed&quot; foreach loop.</div><=
div>=C2=A0</div></div><div>/Georg</div><br><span class=3D"gmail_signature_p=
refix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D=
"ltr"><div><div dir=3D"ltr"><div>Georg Richter, Staff Software Engineer</di=
v><div>Client Connectivity<br></div><div>MariaDB Corporation Ab<br></div></=
div></div></div></div></div>

--0000000000005ac1bd064f6aa5bf--