for example making a select on a table results in a error message like this
"While running SELECT url, fetch_interval, fresh_time, ttl, timeout, time_of_day, next_fetch, latest_request FROM 618e3w_insert_cached_href_0_request : big_query(): Query "SELECT url, fetch_interval, fresh_time, ttl, timeout, time_of_day, next_fetch, latest_request FROM 618e3w_insert_cached_href_0_request " failed (You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '618e3w_insert_cached_href_0_request' at line 1)" this also happens with creates, inserts, deletes and so on i use mysql 5.0.77 greetings thomas 2012/3/11 Martin Stjernholm <[email protected]> > Maybe I was too quick - the mysql manual says: > > Identifiers may begin with a digit but unless quoted may not consist > solely of digits. > > Since the names returned by get_my_table always contain at least one > "_", they ought to be valid even when they begin with digits. What is > the problem you get? > > Martin Stjernholm <[email protected]> wrote: > > > What an awkward problem. :( > > > > Ideally we should use a different name format to ensure it's always a > > valid identifier, but I can't see how we'd solve the compat then. > > > > Still, I'm not so sure it's wise to let get_my_table() start to quote > > the returned table name though; it only works as long as the caller only > > inserts it directly into an sql query, and doesn't do the backtick > > quoting himself. We cannot assume that. > > > > What we can do is fix the backticks internally in DBManager etc, and > > document it. One could consider new alternative functions that return > > quoted names, but I don't think that really improves anything since the > > quoting is very easy to do anyway. > > > > Is there anything else that can be done about this mess? > > > > Thomas Gusenleitner <[email protected]> wrote: > > > >> in Roxen the table names from get_my_table() and related functions > >> should be escaped with `. Because the table names are sometimes > >> starting with digits and this will produce invalid sql statements. >
