Hi all As for the IGNORE keyword - I am not so sure it is necessary to drop it. I will argue this later in this mail.
But hang on - gotto get this off of my chest: Please allow me to clarify that I have thus far not sent any info from the SQL standard out of the blue - in every case where I did post something, it was because someone asked a question earlier in the thread about the standard in relation to the topic of that thread. I happen to be the kind of bean counter that likes to sit down to try and figure out what it is the standard says, esp. if somebody claims that "according to standard SQL ...". I also want to make it clear that I do not think the standard is sacred - Like Monty T pointed out, it is very much a standard that has evolved from current practice, and indeed it is heavily influenced by vendors. (although I don't think that is necessarily a bad thing) Now - about IGNORE. Personally, I don't think it is wrong to support some form of IGNORE. As long as it does not attempt to *change data* and perform the action I think it is very useful. What I like even better is some sort of ON CONFLICT clause like supported by SQLite: http://www.sqlite.org/lang_conflict.html This allows better control over what to do when something happens - and the good news is you don't even lose IGNORE. What would be even nicer is an ON CONFLICT LOG TO option. I mean, seriously, would it not be better to properly write the failed rows to some table instead of into the byte bin also known as warnings? Maybe drizzle can be the first to support that? kind regards. On Mon, Dec 22, 2008 at 11:01 PM, Jay Pipes <[email protected]> wrote: > Monty Taylor wrote: >> >> Brian Moon wrote: >>>> >>>> This would likely mean the dropping of the IGNORE keyword from Drizzle's >>>> SQL syntax. >>> >>> Standards are for breaking. Or is that rules? Really, it *feels* like >>> Drizzle is becoming more about making an SQL standards compliant DBS >>> than one that is fast, maintainable and good for scale out. I >>> understand wanting to have known expectations. But, I have just seen >>> "we should do x because it is the standard" thrown around a lot lately. >>> Whereas, when Drizzle started, the tone was more to use the standard >>> where the standard made sense and not use it when it did not make sense. >>> Maybe it does make sense in this case, but, I just don't see the >>> discussion happening these days. >>> >>> Ok, back to my corner. >>> >> >> /me agrees. >> >> Remember, the SQL Standard wasn't written with making-sense in mind. It >> was written by a committee of database vendors - none of whose opinions >> about things I really care about - and all of whom break the "standard" >> themselves whenever they feel like it. >> >> Up until (and including) now, MySQL and MySQL's behavior has been >> far-and-away the standard for Web. I think if we can build on that but >> make some things clearer, then we win. >> >> For example - considering n00b web devs, if they try something and it >> farts and error back at them, they grok that immediately and they know >> how to deal with that. If it sends a _warning_ ... well, that's a bit >> more esoteric. Are they even going to check that warning? >> >> If you're "ok" with your data being truncated, then truncate it. We >> shouldn't silently modify people's data for them in some situations... >> if we do we'll be more confusing that perl's operator precedence chart. > > I agree 100%. However, what we're essentially talking about isn't in the > "data modification" area. We're talking about examples such that Roland > showed: > > CREATE TABLE t (c CHAR(10)); > INSERT INTO t VALUES ('0123456789'); > SELECT CAST(c AS CHAR(9)) FROM t; > > There's no modification of any data in this case, so what should be the > case? A warning or nothing or an error? > > Roland and Roy have a good point that in these cases, the SQL standard does > in fact provide guidance. > > But, I am in no way trying to stifle discussion here. I'd love to hear from > others. > > -jay > > _______________________________________________ > 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
