Hi! On Mon, May 4, 2009 at 5:23 PM, Jay Pipes <[email protected]> wrote: > Let's get this train back on the tracks... :)
ack ;) > For *quoted* identifiers, there seem to be a number of different viewpoints: Just adding text to define more precisely - not trying to be snotty. > 1) Forget the standard and stick with the current MySQL semantics of > backtick delimiters, double-quote delimiters, and inconsistent current behaviour is: * backtick delimits quoted identifiers * double quote and single quote can both be used as string delimiters > 2) Stick to the SQL standard, which says quoted identifiers should be > compared in a case-sensitive manner and double-quotes should be the one > and only delimiter for quoted identifiers. > > 3) Adopt some hybrid approach which might be something like scrap the > backtick delimiters, but continue to support both single and double > quote string identifiers. correction - not string identifiers, string literals. Keeping quoted identifiers implicies introduction of a new non-standard delimiter for quoted identifiers kind regards, Roland > > Am I missing any specific viewpoints expressed in the thread? > > Personally, I think that #2 would be doable, and it could be broken into > a number of subtasks that contributors could accomplish in a phased > approach. For instance, one task to remove backtick delimiters, one > task to get comparisons for all objects done consistently, and another, > if the community decides it is worth the effort, to go 100% > standard-compatible and remove the double quote string delimiter. > > 1, 2, or 3? or some 4? > > - -jay > > Jim Starkey wrote: >> Tim Soderstrom wrote: >>> Yo Jim! >>> >>> I'm curious as to what your thoughts are in regards to the fact that >>> the standard isn't itself open? Correct me if I'm wrong, but >>> every-time something is added, removed, or changed in Drizzle in terms >>> of syntax, some guy that happens to have a copy of said standard has >>> to validate it? To me, in an open source world, that doesn't make any >>> sense. >> I believe that older and draft versions are available for free. That >> said, I don't think anyone has argued that drizzle implement every silly >> feature that some company get pushed into the standard. There's a lot >> of stuff there are vanity features, things badly thought out, design by >> committee, etc. >> >> My only point is that drizzle should not have *arbitrary* differences >> from the spec. If you have update syntax, you should use the update >> syntax from the standard unless there is an overriding reason not to. >> Extentions are OK. >> >> What is not OK is taking syntax from the standard (like identifiers) and >> deciding your identifiers should behave differently. Maybe your rules >> are better and maybe they are worse, but neither drizzle users nor >> perspective drizzle users are well served with arbitrary differences. >> >> Case in point. SQL triggers bay at the moon (having invented the >> cascading trigger, this is something I have strong feelings about). So >> in Netfrastructure, I ignored SQL standard triggers and implemented >> Java-based triggers instead. But nobody is going to confuse the two. >> It's a difference, but not an arbitrary difference. >> >> The more difficult cases occur when you implement something that gets >> standardized later (this is the only honor place for a database >> developer). Then you have to deal with the hash the drones made of your >> work and figure out how to converge. At Interbase, we innovated in GDML >> and waited for the SQL committee to bless it before moving it into our >> SQL. Unfortunately, that isn't a useful strategy anymore. >>> >>> I know there's stuff in the official SQL standard that doesn't make >>> any practical sense. Implementing those would be, well, impractical :) >>> Drizzle's core is probably not going to need to worry about many of >>> these anyway since they are, if I remember correctly, in relation to >>> views, procedures, objects (I think?), etc. Alot of that seems like it >>> would be a pluggable module into Drizzle anyway. >> See above. >>> >>> So, while bucking the standard isn't a good idea in the grand scheme >>> of things, I think there could be times where it could make sense to >>> do so. The difference is that I think Drizzle's SQL standard should be >>> openly published and freely available for others to implement. In >>> fact, I'd say all the open source DB's and the DB platforms that care >>> should work on an Open SQL standard and adhere to that. >> Sorry, but only an idiot bucks an international standard and declares >> his alternative a de facto standard. There is no difference between >> open source databases and commercial databases, except, perhaps, the >> arrogance of the developers. >> >> If you want to lead the world in features and functionality, go ahead >> and innovate. If you're only playing catch up, you might as follow the >> standard. >> >> Note: It's sometime worth understanding the standard before diverging. >> You might learning something. For example, you would have learned that >> folding to lower case doesn't work for many languages. >>> >>> Until we have an Open SQL standard, while inherently I agree with you, >>> I'm not so sure Drizzle needs to worry so much about the closed SQL >>> standard. Correct me if I'm wrong, but Drizzle is mostly compliant, or >>> at least will be depending on what people decide about those terrible >>> back-ticks. Any place were Drizzle deviates can't be by much since >>> Drizzle doesn't support a huge number of things from the standard in >>> the core. So if Drizzle is just a little off, I would think a simple >>> migration script would allow migrating to and from multiple DBs. >>> That's not ideal, but then again, neither is having to pay money for a >>> silly standard. >> Look, I agree with you about paying for the standard. The SQL standard >> was originally intended as a barrier to entry to the database market. >> Bad idea, and it didn't work. >> >> Let me make a suggestion. Why don't you think about ways to attract >> potential users to drizzle rather than thumbing you nose at them? An >> "open source database standard" would let you poach customers/users from >> PostgresSQL. Why not raise you sights a little higher and endeavor to >> poach users from Oracle or Microsoft? >>> >>> $0.02 >>> >>> Tim >>> >>> P.S. If I'm totally wrong about any of that, feel free to openly flame >>> away :) >> See above. >>> >>> >>> On May 3, 2009, at 2:40 PM, Jim Starkey wrote: >>> >>>> At the risk of boring everyone to death, I'd like to explain a bit >>>> more about why I continue to push a standard I don't like. >>>> >>>> In the computer world, like many others, there comes a time where a >>>> technology is good enough. At that point, something better has a >>>> very high bar to acceptance. Yes, this leads to less than optimal >>>> standards, but a good enough standard allows folks to concentrate on >>>> newer and more interesting stuff. Lotus 1-2-3 was good, but not good >>>> enough. Excel, on the other hand, is widely regarded as good enough, >>>> sufficiently good that competing against it is pointless. X-11 is >>>> another example. X-10 wasn't good enough, X-11 is. Sun's News and >>>> display postscript were both better than X-11, but not sufficiently >>>> better to bother with. >>>> >>>> When the marketplace speaks, one should either listen or prepare for >>>> a life a deep frustration. >>>> >>>> SQL is clearly good enough. It had all sorts of competitors, all of >>>> which are nearly forgotten. SQL won more or less fair and square -- >>>> there were multiple implementations of SQL, mostly incompatible, a >>>> couple of implementations of QUEL, a couple of implementations of the >>>> DEC/Interbase language, and any number of forgotten one-offs. >>>> >>>> Due to pressure from users, the various SQL implementations have >>>> gradually coalesced around an official standard. The process was >>>> ugly and rigged, but the world spoke very clearly that it wanted a >>>> standard database language, and those products that wished to ignore >>>> the standard would be punished. >>>> >>>> MySQL has an idea that it sets it own standard. This is not only >>>> horseshit, but blatantly anti-democratic horseshit. It is the same >>>> horseshit that Oracle and Ingres tried to pull with non-standard SQL >>>> and QUEL -- languages that they controlled and the rest of the world >>>> be damned. >>>> >>>> The MySQL attitude toward SQL is stupid, ignorant, short sighted, >>>> arrogant, and just plain wrong. Interoperability with the rest of >>>> the world is important because it lets people use database software >>>> to solve one set of problems so they can concentrate on other sets of >>>> problems. Throwing roadblocks in front of users that both impede >>>> acceptance of drizzle or MySQL and, not incidentally, prevent users >>>> from converting to other systems, is profoundly unfortunate. >>>> >>>> So, drizzle, join the world or thumb your nose at it and go your own >>>> way. But please don't proclaim out of one side of your mouth that >>>> you are a SQL database system and out the other that you aren't >>>> willing to go beyond lip service to the standard. >>>> >>>> When you have semantics beyond the standard, by all means go your own >>>> way. Innovation should not be stifled by a standard. But if the >>>> only motivation for divergence from the standard is to show the world >>>> that you're smarter than everyone else (or, in the case of MySQL, too >>>> dumb to fix it), give it up and get a life. >>>> >>>> Let the counter-rants begin. >>>> >>>> >>>> -- >>>> Jim Starkey >>>> President, NimbusDB, Inc. >>>> 978 526-1376 >>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~drizzle-discuss >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~drizzle-discuss >>>> More help : https://help.launchpad.net/ListHelp >> >> > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkn/CHcACgkQ2upbWsB4UtHOMQCeNN0sgE0fSbdkKrL/Qj2o+Qw2 > RbcAn1j+BV8j5smhA1+fwd/WADZBtthK > =24ag > -----END PGP SIGNATURE----- > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
