Marcus Welz wrote:
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.
I think that isn't a bad idea necessarily, but in general, more pragmas
means more configuration, means
more mysterious settings that need to be
explained/documented/maintained. SQLite is against requiring
configuration.
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
But if it's supported in sqlite, they'll never migrate away from it.
Supporting something that's
non-standard because it makes it easier to migrate code isn't, to me,
enough justification. Supporting
something that's non-standard because it makes it easier to do something
important can be a good
idea. Fixing your sql to be standard is something you need to do
whenever you switch away from
mysql, no matter what you're migrating to.
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
John LeSueur
