Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130670
Precedence: list
MIME-Version: 1.0
References: <CAANVRFiatY+SJdmEf56wzOvY5_9QmH7BtMB6yPzbt1xatYc_1A@mail.gmail.com>
 <CAGBsUrezVkQNtYbKENJ-emZY-ccZvEVhnjPmnL9YBofsXJmjcw@mail.gmail.com>
 <CAANVRFgDsmw2v=ue=hyJTgE57k1qEQNZ_immxjCWZY0hQv08dg@mail.gmail.com>
 <CAGBsUrc++XbrVcMMcc6WzwBvD8ui87CXVhXSR6uTC_YbfziE0Q@mail.gmail.com> <CADjdLZ+VY8A-LY2vSKm3YOcMrTswsX4763q3kSTC20pFT1BJWw@mail.gmail.com>
In-Reply-To: <CADjdLZ+VY8A-LY2vSKm3YOcMrTswsX4763q3kSTC20pFT1BJWw@mail.gmail.com>
Date: Sun, 19 Apr 2026 23:07:15 +0200
Message-ID: <CAANVRFiN9t_kLyQjmHomGYNZ-w6F5uq_tw5ufKB66RKXP9Yb0g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC][Discussion] Add MariaDB-specific features to
 mysqlnd and mysqli
To: Robert Humphries <contact@developer-rob.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000c0873c064fd69129"
From: georg@mariadb.com (Georg Richter)

--000000000000c0873c064fd69129
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Robert,

When I designed and wrote mysqli (and parts of libmysql 4.1) nearly 25
years ago, the computing landscape was fundamentally different. Memory was
a severe constraint; allocating large buffers to send data all at once was
often impossible. This necessitated the use of mysql_stmt_send_long_data to
stream larger BLOBs in portions=E2=80=94which was a primary reason for requ=
iring
the explicit types specification in mysqli_stmt::bind_param.

Furthermore, CPU power was significantly more limited. The overhead of
converting types between the client and server was expensive. By providing
explicit type hints (like "isss"), we gave the engine a shortcut, bypassing
the need for the driver to "guess" or perform trial-and-error casts, thus
saving precious cycles at both ends of the connection.

Twenty-five years later, the landscape has evolved. Physical memory is
rarely the bottleneck; we are now primarily limited by the
max_allowed_packet size. Modern hardware and the maturity of libraries mean
that the CPU cost of internal type-juggling is now negligible for the vast
majority of applications.

However, we must avoid the "sledgehammer" approach of deprecation. In
high-speed, high-concurency environments where packet size and execution
speed remain fundamental requirements, the ability to explicitly define
types is still important. It allows for the most efficient binary
serialization possible, which is critical for the "power-user" tier of the
PHP ecosystem.

/Georg


On Sun, Apr 19, 2026 at 3:45=E2=80=AFPM Robert Humphries <
contact@developer-rob.co.uk> wrote:

> > Despite your convincing arguments for better network utilization by
> > providing the types, I still think we should not offer the possibility
> > of specifying the types. I don't know what other PHP developers on
> > this mailing list think about it, but for me the type feature goes
> > against the nature of PHP. Making the parameter optional is very good
> > choice and eases my concerns slightly, so if I am outnumbered in my
> > opinion, I won't be upset.
> > The number of mysqli users grows increasingly smaller. Out of this,
> > the number of people who will use execute_many and who will need to
> > optimize for TINYINT is unbelievably tiny. Any string easily
> > overshadows the numerical data. Thus, this feature won't see much
> > legitimate use.
>
> I think the risk here is that currently the `types` parameter is
> supported in existing code (via `bind_param`); and it is not
> deprecated / no warnings exist on its usage in the manual. I think
> having the parameter in new code be optional was a sensible change;
> but until `mysqli_stmt::bind_param` is deprecated or the `types`
> parameter is removed there; allowing users to specify the types in new
> functions where there is a benefit to doing so (even if only a small
> number of people will use the benefit) makes sense to do unless there
> are technical or other reasons not to. If setting types for a prepared
> statement shouldn't be done in PHP, then where that currently can be
> done should be deprecated and in the future removed.
>


--=20
Georg Richter, Staff Software Engineer
Client Connectivity
MariaDB Corporation Ab

--000000000000c0873c064fd69129
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Robert,</div><div><br></div><div>When I designed a=
nd wrote mysqli (and parts of libmysql 4.1) nearly 25 years ago, the comput=
ing landscape was fundamentally different. Memory was a severe constraint; =
allocating large buffers to send data all at once was often impossible. Thi=
s necessitated the use of mysql_stmt_send_long_data to stream larger BLOBs =
in portions=E2=80=94which was a primary reason for requiring the explicit t=
ypes specification in mysqli_stmt::bind_param.<br><br>Furthermore, CPU powe=
r was significantly more limited. The overhead of converting types between =
the client and server was expensive. By providing explicit type hints (like=
 &quot;isss&quot;), we gave the engine a shortcut, bypassing the need for t=
he driver to &quot;guess&quot; or perform trial-and-error casts, thus savin=
g precious cycles at both ends of the connection.<br><br>Twenty-five years =
later, the landscape has evolved. Physical memory is rarely the bottleneck;=
 we are now primarily limited by the max_allowed_packet size. Modern hardwa=
re and the maturity of libraries mean that the CPU cost of internal type-ju=
ggling is now negligible for the vast majority of applications.<br><br>Howe=
ver, we must avoid the &quot;sledgehammer&quot; approach of deprecation. In=
 high-speed, high-concurency environments where packet size and execution s=
peed remain fundamental requirements, the ability to explicitly define type=
s is still important. It allows for the most efficient binary serialization=
 possible, which is critical for the &quot;power-user&quot; tier of the PHP=
 ecosystem.</div><div><br></div><div>/Georg</div><div><br></div></div><br><=
div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g=
mail_attr">On Sun, Apr 19, 2026 at 3:45=E2=80=AFPM Robert Humphries &lt;<a =
href=3D"mailto:contact@developer-rob.co.uk">contact@developer-rob.co.uk</a>=
&gt; wrote:<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">&gt;=
 Despite your convincing arguments for better network utilization by<br>
&gt; providing the types, I still think we should not offer the possibility=
<br>
&gt; of specifying the types. I don&#39;t know what other PHP developers on=
<br>
&gt; this mailing list think about it, but for me the type feature goes<br>
&gt; against the nature of PHP. Making the parameter optional is very good<=
br>
&gt; choice and eases my concerns slightly, so if I am outnumbered in my<br=
>
&gt; opinion, I won&#39;t be upset.<br>
&gt; The number of mysqli users grows increasingly smaller. Out of this,<br=
>
&gt; the number of people who will use execute_many and who will need to<br=
>
&gt; optimize for TINYINT is unbelievably tiny. Any string easily<br>
&gt; overshadows the numerical data. Thus, this feature won&#39;t see much<=
br>
&gt; legitimate use.<br>
<br>
I think the risk here is that currently the `types` parameter is<br>
supported in existing code (via `bind_param`); and it is not<br>
deprecated / no warnings exist on its usage in the manual. I think<br>
having the parameter in new code be optional was a sensible change;<br>
but until `mysqli_stmt::bind_param` is deprecated or the `types`<br>
parameter is removed there; allowing users to specify the types in new<br>
functions where there is a benefit to doing so (even if only a small<br>
number of people will use the benefit) makes sense to do unless there<br>
are technical or other reasons not to. If setting types for a prepared<br>
statement shouldn&#39;t be done in PHP, then where that currently can be<br=
>
done should be deprecated and in the future removed.<br>
</blockquote></div><div><br clear=3D"all"></div><br><span class=3D"gmail_si=
gnature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><d=
iv dir=3D"ltr"><div><div dir=3D"ltr"><div>Georg Richter, Staff Software Eng=
ineer</div><div>Client Connectivity<br></div><div>MariaDB Corporation Ab<br=
></div></div></div></div></div>

--000000000000c0873c064fd69129--