[wp-trac] [WordPress Trac] #12819: wpdb::prepare support for null

WordPress Trac noreply at wordpress.org
Mon Dec 24 11:41:24 UTC 2012

#12819: wpdb::prepare support for null
 Reporter:  roxaz        |       Owner:  ryan
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  Future Release
Component:  Database     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |
Changes (by jbutkus):

 * cc: butkus.justas@… (added)


 What would you think, on using two-step aproach?

 1. Iterate over all values (args) and replace PHP {{{NULL}}} values with
 generated random hashes (at least 2^64^ in complexity) - remembering all

 2. Perform current {{{vsprintf}}} operation and replace former NULLs:

     2.1. First by unquoting possibly quoted values (as NULL may be textual
 ''or'' numeric column): {{{~= s/'$hash'/$hash/g)}}} ,

     2.2. Then by actually replacing them with NULLs: {{{~=

 Why I propose replacement-based solution is that other way round would be
 implementing fully-fledged string parsing, to decode positional
 information, and one would have to take into account all sorts of
 possibilies (i.e. {{{INSERT INTO foo ( col1, col2, col3 ) VALUES ( %2$s,
 %3$d, %s ) ON DUPLICATE KEY UPDATE SET col3 = %3$s, col2 = %s }}}).

 With replacement the only side effect may be replacing some actual value
 for NULL. What is the possibility with key of 2^64^? We can easily minify
 the possibility, by increasing it to 2^256^, as hashing functions are fast
 enough, and simply concatenating output of several of these may resolve
 most of errors.

 Of course, parsing string would be better, but it is way more complicated
 and more errors may creep-in.

 I may opt-in to provide sample solution. Just that some thoughts on this
 are more than welcome.

Ticket URL: <http://core.trac.wordpress.org/ticket/12819#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list