Dr. Hipp isn't showing his hand here, but the timeline indicates that he
added support for MySQL-style backquote quoting on Saturday:
http://www.sqlite.org/cvstrac/chngview?cn=2591

--Ned.
http://nedbatchelder.com
 

-----Original Message-----
From: Marcus Welz [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, 10 August, 2005 4:23 PM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] RFC Beginning digit in column name

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]


Reply via email to