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 <[email protected]> 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.
