incorrect use of %s and db_escape_string()

statistics_title_list():

1. %s should use for user query argument filtering, not as normal string replacement.
2. All 3 target fields: totalcount, daycount and timestamp are INT, so should use 0 (integer compare) instead of '0' (string compare).

system_cron():

1. Both status and query argument are INT, so should use %d instead of %s.

I mark this into my personal research project issue.

Patch reroll via latest CVS HEAD. Test without ill effect.

Just hope to promote if we are able to fix this within D6 RC1.

(I merge http://drupal.org/node/199214 with this issue.)

I try to use db_escape_table(): correct in syntax and function, but not logically suitable (we hope to escape column, not table)...

I try to folk db_escape_table() as db_escape_column(): this seems too ugly and not elegant...

Finally, I try rename db_escape_table() as db_escape_constraint(). As term "constraint" is a superset of "table" and "column", the meaning should be more suitable and general. I dig into all core code, and found that db_escape_table() is now used as internal, only. Hope this change would be acceptable.

Actually... totally agree...

So may I ask for some suggestion? Should I reuse db_escape_table() for incorrect meaning, or folk it as db_escape_column() for a not elegant handling? Either one solution should function correctly.

P.S. maybe we can use embed checking within each function. This should be the least impact to API, but most ugly...

Folk db_escape_table() as db_escape_column().

If a simple documentation can solve this logical conflict, it should be the most simple solution?

Patch update and reroll via CVS HEAD. Bugfix with:

1. Within tablesort_sql(), $sql may sometime contain . as alias.column syntax. It is a special case and so need special handling.
2. Within tablesort_sql(), $sort is assume as asc or desc ONLY. As we are filtering a SQL reserved word, it is also a special case.
3. Within database.mysql.inc, database.mysqli.inc and database.pgsql.inc, contain some improper use of %s. db_escape_table() should be a better choice.

Fix database.pgsql.inc miss handling.

Some update:

1. Use (bool) instead of TRUE: FALSE
2. Remove the use of implode() (right, it is just something fancy...)
3. Patterns in tablesort code should be correct, as it is functioning and logically correct. Right that seems I am now working for a white list approach, and I even trying t restrict $sort as ASC and DESC only (but too fancy, seems not such necessary...)

- I hate $ts['sql'] too... so rename it as $ts['field'] (I don't know if this will void the rule of not changing API...). It is used internally, and tested as function. On the other hand, as $ts['field'] may represent in "alias.field" format, it is different from normal column filtering.
- Now I give a more explicitly checking for $ts['sort']: only allow ASC or DESC.

I am also finding for a better solution... Thanks for your suggestion :)

P.S. Should I update statistics_title_list() into in_array() handling? Seems we only allow 3 choices.

- statistics_title_list() is related because it use %s for column name filtering, which is also included in previous patches. Since we only allow 'totalcount', 'daycount' and 'timestamp' as valid $dbfield input, I guess we should also use in_array() for a faster and explicitly checking.
- Sorry for misunderstanding, and array key is now keep as unchanged. Only fix function internal variable naming.

Additional minor catch in database.pgsql.inc: db_last_insert_id() is in similar case and so change handle with db_escape_table().