Prepared statements are good practice and recommended in places such as https://www.php.net/manual/en/pdo.prepared-statements.php. There are use cases for using them with many items in an IN() clause, or when inserting many rows in a single INSERT statement. In such cases, you can easily end up with more than 999 parameters.
While sqlite can be compiled with a larger SQLITE_MAX_VARIABLE_NUMBER flag, there are situations where the application developer doesn't have control over how the system libraries are compiled. For example, a given PHP application could run on either a stock Debian/Ubuntu installation, a stock Fedora/RHEL/CentOS installation, or other systems. Debian compiles sqlite with SQLITE_MAX_VARIABLE_NUMBER=250000 <https://sources.debian.org/src/sqlite3/3.27.2-3/debian/rules/#L50> (issue <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717900>) whereas Fedora doesn't set the flag <https://git.centos.org/rpms/sqlite/blob/c8/f/SPECS/sqlite.spec#_152> (issue <https://bugzilla.redhat.com/show_bug.cgi?id=1798134>), so gets sqlite's default. According to some of the answers on https://stackoverflow.com/questions/6581573/what-are-the-max-number-of-allowable-parameters-per-database-provider-type, PostgreSQL and some other databases support a 16 bit parameter count (64K parameters). Given current memory availability, can sqlite's default be raised to something similar to that? _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
