SQLite pdo::quote use x'hex' syntax for null bytes #13962
Conversation
| -> '' | ||
| x -> 'x' | ||
| \u0000 -> x'00' | ||
| a\u0000b -> x'610062' |
There was a problem hiding this comment.
| a\u0000b -> x'610062' | |
| a\u0000b -> (''||x'610062') |
quote function should not change type - https://dbfiddle.uk/ZodKR71s
There was a problem hiding this comment.
I actually think datatype blob is perfectly reasonable for binary strings, but okay, 3e573cf
There was a problem hiding this comment.
One reason for "always text type" is as non-UTF-8 string like 0xff is currently "text type" and not "blob type".
There was a problem hiding this comment.
hmmm see #13956 (comment)
there are both pros and cons with retaining the "text type" 🤔
There was a problem hiding this comment.
"nul byte" is supported in "text type" as long as you use it from php :)
divinity76
force-pushed
the
fix-gh13952-simple
branch
from
3e573cf
to
dd5274e
Compare
Implements x'hex' encoding in pdo::quote for handling strings with null bytes, providing a reliable workaround for issue phpGH-13952. An alternative fix is discussed in PR php#13956 PR php#13956 does something interesting, it avoids the overhead of copying to/from sqlite3_snprintf, probably speeding up PDO::quote, but right now I just want to keep things simple. Co-authored-by: Niels Dossche <nielsdos@php.net>
divinity76
force-pushed
the
fix-gh13952-simple
branch
from
dd5274e
to
a03f7d5
Compare
|
Thanks for working on this. However, I'm a bit skeptical of such workarounds. I feel like it's a bit excessive to use PHP to do something that the original SQLite doesn't support. For example, let's say that in the future SQLite supports this and we have to update these functions to match the changes in the SQLite specification. At that point, a BC Break may be unavoidable. However, there is still some time until the release of 8.4. I might leave this PR open for a little while, but I'll try to bring it upstream tonight, so give me some time. |
well the way i see it, there's 4 proposed fixes, all have their own pros and cons, and we haven't really reached a consensus, the proposals are: or or or |
resolves issue phpGH-13952, this is basically a smart_str() version of PR php#13956 per php#13962 (comment) this is 1 of the 4 proposed alternatives to the problem, and the pros of this solution is that it produces smaller queries than the alternatives, and retains the sqlite datatype 'string' (instead of changing it to blob), and should make PDO::quote faster as we now avoid the overhead of copying data to/from sqlite3_snprintf. The cons of this solution, that I can think of right now, is that the implementation is non-trivial, involves a bunch of php-allocator-reallocs() (PR php#13956 does not invovle reallocs, as it pre-computes the length. also worth noting that php allocator's reallocs() are faster than libc realloc, often avoiding talking to the OS), and SQLite's LENGTH(('foo'||x'00'||'bar')) returns 3 instead of 7, and binary strings gets the datatype 'string' instead of 'blob' (that can be considered both a pro and a con) Co-authored-by: Niels Dossche <nielsdos@php.net>
Implements x'hex' encoding in pdo::quote for handling strings with null bytes,
providing a reliable workaround for issue GH-13952.
An alternative fix is discussed in PR #13956
PR #13956 does something interesting, it avoids the overhead of copying to/from sqlite3_snprintf, probably speeding up PDO::quote,
but right now I just want to keep things simple.