Re: [RFC] PDO binary parameter support

Sorry for the later response and not doing the follow-ups on the previous email, I got incredibly busy with PHP stuff at work... you can guess why. On Nov 1, 2026, at 12:39 PM, Ilia <ilia@ilia.ws> wrote: > > Content sniffing can't settle this. A bytea or varbinary value can be valid text, and text > can contain a NUL, so the driver has to be told. It also doesn't help native prepares: > pdo_pgsql sends text-format parameters as C strings, so they truncate at the first NUL regardless of > quoting. That's the strongest argument for the RFC imho. Agreed a binary param type is unavoidable for quoters. > The driver break decides between using a type versus a flag. A new type 6 is a fatal error in > pdo_sqlsrv and IM001 in pdo_ibm until each driver ships an update. A flag that core masks before > quoting allows fetch to fall back to STR/LOB in any driver that ignores it. I'd go with the > flag, and reject combinations with INT/BOOL/NULL with a ValueError. We have shipped breaking changes in PDO before (i.e. zend_stringification), so expecting these drivers to update for newer releases isn't unreasonable. But easing compatibility is another small point in favour of the flag. > pdo_sqlite already marks blobs in getColumnMeta()'s "flags" array, which is a > good precedent for leaving pdo_type alone. Sounds like we can just make it a standard part of the array's expected values then.