Interest in a binary parameter type in PDO?

php.internals

Calvin Buckley

1 year ago
Hi internals, I've been debugging some recent issues users have had, as well as discussing some related ones. I've come to the conclusion there's a lot issues with applications trying to access binary data via PDO drivers. For example - Binary data when quoting in SQL Server can easily get mangled, as the quoter can't handle binary data and truncates the string. It's possible other drivers are like this too. - ODBC drivers can be unpredictable behaviour wise when binding binary data as SQL_C_CHAR (like what the get_col handler does). In the case of one driver, it will hex encode the data and can confuse the size handling in the get_col handler. I've thought about overriding the LOB semantics for quick fixes, but this isn't the right solution, as a LOB and binary data are orthogonal; i.e. CLOBs are LOB strings and VARBINARY doesn't have LOB semantics. A binary type (or modifier, i.e. like intl/natl, not to bikeshed tho) can also be used w/ string columns in the database to possibly override i.e. automatic charset encoding changes from an ODBC driver. I had previously made an issue and PR (links below), but I'm discussing on internals to revitalize the conversation after being motivated by recent issues. I'd like to hear from users, database extn. developers, and userland database library extension developers if this is the right approach, and if I should move forward dusting off the PR and probably writing an RFC. Said PR includes the changes needed for DBLIB, ODBC, and SQLite driver wise, as well as some tests. MySQL/Postgres/Firebird support would need to be added. ~calvinb [issue]: https://github.com/php/php-src/issues/11462 [pr]: https://github.com/php/php-src/pull/11674

Gina P. Banyard

1 year ago
On Wednesday, 23 October 2024 at 17:36, Calvin Buckley <calvin@cmpct.info> wrote:
> Hi internals, > > I've been debugging some recent issues users have had, as well as > discussing some related ones. I've come to the conclusion there's a lot > issues with applications trying to access binary data via PDO drivers. > > For example > > - Binary data when quoting in SQL Server can easily get mangled, as the > quoter can't handle binary data and truncates the string. It's > possible other drivers are like this too. > - ODBC drivers can be unpredictable behaviour wise when binding binary > data as SQL_C_CHAR (like what the get_col handler does). In the case > of one driver, it will hex encode the data and can confuse the size > handling in the get_col handler. > > I've thought about overriding the LOB semantics for quick fixes, but > this isn't the right solution, as a LOB and binary data are orthogonal; > i.e. CLOBs are LOB strings and VARBINARY doesn't have LOB semantics. A > binary type (or modifier, i.e. like intl/natl, not to bikeshed tho) can > also be used w/ string columns in the database to possibly override i.e. > automatic charset encoding changes from an ODBC driver. > > I had previously made an issue and PR (links below), but I'm discussing > on internals to revitalize the conversation after being motivated by > recent issues. I'd like to hear from users, database extn. developers, > and userland database library extension developers if this is the right > approach, and if I should move forward dusting off the PR and probably > writing an RFC. Said PR includes the changes needed for DBLIB, ODBC, and > SQLite driver wise, as well as some tests. MySQL/Postgres/Firebird > support would need to be added. > > ~calvinb > > [issue]: https://github.com/php/php-src/issues/11462 > [pr]: https://github.com/php/php-src/pull/11674
Sorry for the late reply, I think this makes a lot of sense and would be in favour of including this in PDO. Best regards, Gina P. Banyard

Matteo Beccati

1 year ago
Hi, as mentioned in https://github.com/php/php-src/pull/15949 I still think that PARAM_LOB can safely be used as identifier for binary data, as pdo_mysql and pdo_pgsql do. Cheers On 15/06/2025 16:52, Gina P. Banyard wrote:
> On Wednesday, 23 October 2024 at 17:36, Calvin Buckley <calvin@cmpct.info> wrote: > >> Hi internals, >> >> I've been debugging some recent issues users have had, as well as >> discussing some related ones. I've come to the conclusion there's a lot >> issues with applications trying to access binary data via PDO drivers. >> >> For example >> >> - Binary data when quoting in SQL Server can easily get mangled, as the >> quoter can't handle binary data and truncates the string. It's >> possible other drivers are like this too. >> - ODBC drivers can be unpredictable behaviour wise when binding binary >> data as SQL_C_CHAR (like what the get_col handler does). In the case >> of one driver, it will hex encode the data and can confuse the size >> handling in the get_col handler. >> >> I've thought about overriding the LOB semantics for quick fixes, but >> this isn't the right solution, as a LOB and binary data are orthogonal; >> i.e. CLOBs are LOB strings and VARBINARY doesn't have LOB semantics. A >> binary type (or modifier, i.e. like intl/natl, not to bikeshed tho) can >> also be used w/ string columns in the database to possibly override i.e. >> automatic charset encoding changes from an ODBC driver. >> >> I had previously made an issue and PR (links below), but I'm discussing >> on internals to revitalize the conversation after being motivated by >> recent issues. I'd like to hear from users, database extn. developers, >> and userland database library extension developers if this is the right >> approach, and if I should move forward dusting off the PR and probably >> writing an RFC. Said PR includes the changes needed for DBLIB, ODBC, and >> SQLite driver wise, as well as some tests. MySQL/Postgres/Firebird >> support would need to be added. >> >> ~calvinb >> >> [issue]: https://github.com/php/php-src/issues/11462 >> [pr]: https://github.com/php/php-src/pull/11674 > > Sorry for the late reply, > > I think this makes a lot of sense and would be in favour of including this in PDO. > > Best regards, > > Gina P. Banyard
-- Matteo Beccati Development & Consulting - http://www.beccati.com/ -- Matteo Beccati Development & Consulting - http://www.beccati.com/