Hello there, I think that adhering to standards is a Very Good Thing(tm). They are standards for a reason. Deviations can introduce ambiguity, confusion, complexity, vendor lock-ins and all sorts of other headaches.
That said, however, I believe that "no, because it's not the standard" isn't exactly what a customer wants to hear. Then again "no" isn't what a customer wants to ever hear in almost any context, but I digress.. Customers / users may wonder "Well, they (e.g. MySQL) can do it, why can't you?" And I think in a fair number of situations, if possible to implement at a reasonable amount of cost the answer should be "We can, but be warned, it is NOT the standard." Some proprietary extensions are rather handy, too, and may want be be considered. I don't really think "`" and "[]" are useful nor pretty, but I also don't think that it would be unethical to support it. On the other hand, MySQL's "SQL_CALC_FOUND_ROWS" keyword and the "FOUND_ROWS()" function for instance have made my life easy in the past. (SQL_CALC_FOUND_ROWS in a query counts how many rows there would have been returned with the LIMIT clause omitted, great for pagination if you want to display something like "Rows 1 - 15, 400 total" all while running a complex query (with a whole slew of JOINS and WHERE conditions) only once. The short of it all: I don't know much about SQLite's internal architecture, besides glossing over the web site documentation, but my suggestion is to add a new PRAGMA statement ("PRAGMA tolerate_broken_sql = 1" :-), which should be _disabled_ by default, but when enabled would honor proprietary extensions such as "[]" and "`" for quotation, digits in column names, and who knows, maybe even some of the other extensions and vendor specific functions, etc. It would allow numerous projects to more easily migrate away from MySQL to SQLite without needing to clean up all their broken SQL instantly, and it would allow projects that want to stick with MySQL to also offer a SQLite version with little effort. How off the wall am I with this? -m -----Original Message----- From: Austin Ziegler [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 10, 2005 2:44 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] RFC Beginning digit in column name On 8/10/05, ender <[EMAIL PROTECTED]> wrote: > Austin Ziegler wrote: >>On 8/9/05, ender <[EMAIL PROTECTED]> wrote: >>> So my simple feature request would be: allow '`' as a quoting symbol - >>> as mySQL does. Or - what would be as helpful as the other idea - allow >>> unquoted column names with leading digits - as mySQL does. >>> Also see ticket # 1337 http://www.sqlite.org/cvstrac/tktview?tn=1337 >> I think that supporting '`' (backquote) would be a bad idea. Then >> again, MySQL ignores so much of the SQL standard that I think that >> importing any idea from MySQL is a bad idea. > What are your reasons for thinking supporting '`' is a bad idea? 1. It's not part of the standard. 2. It's not part of the standard. 3. MySQL does it. Therefore, no one else should do it, because: 4. It's not part of the standard (and most of what MySQL does is not part of the standard). If you've learned "SQL" on MySQL, you haven't learned SQL. You've learned MySQL. The same applies to people who want to do [tablename] -- it's a Microsoftism that (IMO) should be *de-supported* in SQLite because it's ugly and wrong. The only quotes that SQL92 supports are ' and "; ' indicates data, " indicates literal interpretation of table and column names. Not `, not []. If MySQL does it and it's not part of the standard, I'm opposed to it. -austin -- Austin Ziegler * [EMAIL PROTECTED] * Alternate: [EMAIL PROTECTED]