-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Let's get this train back on the tracks... :)
An ongoing debate about standards is certainly interesting, but let's try to stick to the specifics this thread was about, otherwise we run the risk of academic debates with no end. In short, there are two main things at issue in the original thread: * The consistent handling of *non-quoted* identifiers * The consistent handling of *quoted* identifiers The two can be worked on separately, and Avi K has begun work on the first part of the above. The community seemed pretty much in agreement on non-quoted identifiers, and there's a bunch of work to be done in the kernel to fix up all the different ways in which object identifiers are instantiated. Avi is currently detailing all these different methods and will work towards a lean hierarchy of C++ classes which will be used in the kernel and in plugins to reference objects inside the server. For *quoted* identifiers, there seem to be a number of different viewpoints: 1) Forget the standard and stick with the current MySQL semantics of backtick delimiters, double-quote delimiters, and inconsistent storage-engine behaviour. This clearly would be the easiest for migration concerns, although it has been mentioned that a mysql_compat plugin could ease migration concerns using a rewrite engine. 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. 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
