Seems like there are several ways to skin this cat. The problem I have with CHECK is the generic error message it produces. If a table has several columns with CHECK statements, how does my application know which one failed? I favor the trigger approach because I can define a meaningful error message.
On Sat, Mar 9, 2013 at 9:00 AM, <sqlite-users-requ...@sqlite.org> wrote: > Message: 17 > Date: Fri, 8 Mar 2013 14:26:06 -0500 > From: "James K. Lowden" <jklow...@schemamania.org> > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] SQLite strong-typing [WAS: inner vs. outer join > inconsistency] > Message-ID: <20130308142606.15776668.jklow...@schemamania.org> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, 7 Mar 2013 19:20:44 +0100 > Petite Abeille <petite.abei...@gmail.com> wrote: > > > > In conclusion, if you want to allow affine type conversions on > > > INSERT, but not disallow values that cannot be so converted, then > > > CHECK(my_column = CAST(my_column AS <TYPE>)) works. And if you want > > > to disallow values of incorrect types even when type conversion is > > > possible then use CHECK(typeof(my_column = <TYPE>). That's pretty > > > cool, IMO. > > > > Yeah? 'cool' is not necessarily how I would describe it? having a > > check constraint 'magically' coerce - change! - the inserted data > > type is? well? not cool. I would call it a misfeature :) > > To be clear, the contraints Nico described don't coerce anything. By > preventing the insertion of values outside the column's domain (per its > affinity), the constraints ensure that future coersions -- as part of a > join, say -- won't lose data. > Pete lcSQL Software <http://www.lcsql.com> _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
