On Wed, Oct 8, 2014 at 1:26 AM, Simon Slavin <slav...@bigfraud.org> wrote:
> > You could probably use a TRIGGER that detects the type of row you don't > want and replaces it with your preferred form. This doesn't do exactly > what you want, but it is something like it. > > That'd work, but extra effort and more potential debugging if a problem comes up. But getting into triggers I think goes more into your next point of internally programming the engine via a language instead of the engine going to the user and saying STAHP!! > SQL doesn't detail any method of communicating with the user (or even the > programmer). From its origins as a simple demonstration of a concept it > has grown so powerful that people try to do programming in it without using > a proper programming language. It may be that a new procedural data > manipulation language will come along one day but I think it will allow the > programmer to define data conflict in a more elegant manner. > CTEs anyone? ;) I can see where you're coming from in that it might be more important to let the programmer know about potential faults via raised exceptions, but we've already got the IGNORE definition which could potentially cause data loss instead of internal data manipulation. Knowing you can't catch everything without a very bloated and slow program, for some things, I think it'd be alright if the engine took care of itself with the provisions provided by the database author. In my mind, if a default is given, and an exception is raised due to a constraint, going back to a safe place with safe data might be better than an exception being raised and just have another thing to deal with. Data loss is HORRIBLE, but, data manipulation in certain criteria (As like in my example where a boolean can't have three results -- True/False/NULL) by adding a single verb to the table construct seems more palatable to me. Can one not also put a constraint up on the field to say that the field can only be of a certain value, kind of to emulate ENUM? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
