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—which was a primary reason for requiring 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 PM Robert Humphries < [email protected]> 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. > -- Georg Richter, Staff Software Engineer Client Connectivity MariaDB Corporation Ab
