[wp-trac] [WordPress Trac] #54042: Extending wpdb::prepare() to support table/field names, and IN() operator

[WordPress Trac]

#54042: Extending wpdb::prepare() to support table/field names, and IN() operator
-------------------------------------------------+-------------------------
 Reporter:  craigfrancis                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback needs-        |     Focuses:
  testing early has-unit-tests                   |
-------------------------------------------------+-------------------------

Comment (by craigfrancis):

 Thank you @apokalyptik, I really appreciate your time and thoughts that
 have gone into this.

 When you say "a single not-currently-used character", can you expand on
 that? The only reason I went with `...` is because it matches variadics in
 PHP, and because I think it would help someone seeing it for the first
 time guess what it's doing (i.e. it's an ellipsis, which has meaning in
 the English language already). And while I appreciate a comma (a single
 character) is similar to `$` for parameter number, and `.` for precision,
 if [https://en.wikipedia.org/wiki/Printf_format_string printf] was to
 change in the future (I know, highly unlikely), I suspect it would be more
 likely to use a comma (to follow their single character pattern), and that
 would create a compatibility issue.

 The `$arg_identifiers` are separate so I can easily
 [https://github.com/craigfrancis/wordpress-
 develop/blob/db5ab0881c5740f9ec6df9134709ae43ebbf3689/src/wp-includes/wp-
 db.php#L1641 escape them differently], and to trigger the "cannot be used
 for both String and Identifier escaping" error. As in, if someone tried to
 use the same value in both a string/number and identifier context (odd,
 but it might happen), because they cannot be escaped in the same way, I
 need to reject that, and ask them to provide the value twice, e.g.

 {{{#!php
 <?php
 $wpdb->prepare( 'WHERE %i LIKE "%1$s" LIMIT 1', [ 'aaa', false ] ); //
 Sorry, no can do.
 $wpdb->prepare( 'WHERE %i LIKE %s LIMIT 1', [ 'aaa', 'aaa' ] );
 }}}

 Also, some of the choices were to keep the performance/memory impact
 really low (it's generally about the same, and in some cases can be even
 faster due to less RegEx work).

 If you want to propose any changes, I've got a
 [https://github.com/craigfrancis/wordpress-develop/tree/ticket-54042
 branch on GitHub], and happy to discuss here and off-list, but keep in
 mind the diff from [https://github.com/craigfrancis/wordpress-
 develop/tree/ticket-52506 ticket-52506] (to add support for identifiers)
 is quite small (unfortunately GitHub [https://github.com/craigfrancis
 /wordpress-develop/compare/ticket-52506...craigfrancis:ticket-54042
 compare] seems to be broken, [https://github.com/craigfrancis/wordpress-
 develop/blob/ticket-52506/src/wp-includes/wp-db.php#L647 A] vs
 [https://github.com/craigfrancis/wordpress-develop/blob/ticket-54042/src
 /wp-includes/wp-db.php#L647 B]).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54042#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform