Re: [sqlite] feature proposal - strong but dynamic typing

Darren Duncan wrote: > Roger Binns wrote: > >>> In fact this support might even be easier as it may only require >>> enhancements to >>> the SQL parser, which would generate VM opcodes like for a CHECK >>> constraint, >>> unless further work is done to optimize for the presented cases, or

Re: [sqlite] feature proposal - strong but dynamic typing

On Fri, Oct 30, 2009 at 03:59:11PM -0500, Jay A. Kreibich wrote: > On Fri, Oct 30, 2009 at 03:19:59PM -0500, Nicolas Williams scratched on the > wall: > > I should add that a pragma that cause CHECK constraints to be > > automatically created for enforcing strong typing in subsequent CREATE > >

Re: [sqlite] feature proposal - strong but dynamic typing

On Fri, Oct 30, 2009 at 03:19:59PM -0500, Nicolas Williams scratched on the wall: > I should add that a pragma that cause CHECK constraints to be > automatically created for enforcing strong typing in subsequent CREATE > TABLE statements That's tricky. Values have TYPES. Columns have

Re: [sqlite] feature proposal - strong but dynamic typing

I think that something several people had missed was that I specifically proposed the strong typing behavior to be activated by a new pragma, and unless people activate that pragma they would get the old behavior, so total backwards compatibility. I see several people then proposed using the

Re: [sqlite] feature proposal - strong but dynamic typing

I should add that a pragma that cause CHECK constraints to be automatically created for enforcing strong typing in subsequent CREATE TABLE statements is rather like having FOREIGN KEY clauses automatically generate triggers. There's precedent, in other words, and it is a simple way to implement

Re: [sqlite] feature proposal - strong but dynamic typing

On Fri, Oct 30, 2009 at 01:30:31PM -0400, John Crenshaw wrote: +1 I don't think this proposal can or will be accepted. One reasonable idea, perhaps, would to have a pragma that causes subsequent CREATE TABLE statements to get automatically generated CHECK expressions that enforce typing. Any

Re: [sqlite] feature proposal - strong but dynamic typing

> I believe I understand Darren's point (whether or not I care for them > is another story). Yes, you've understood Darren for the most part, but clearly don't understand the objections. > On Fri, Oct 30, 2009 at 2:22 AM, Roger Binns wrote: > > -BEGIN PGP SIGNED

Re: [sqlite] feature proposal - strong but dynamic typing

On 30 Oct 2009, at 2:14pm, P Kishor wrote: > Actually, there can be one bad effect of Darren's suggestion, now that > I think of it, and that would be for those who don't care for strong > typing. They will end up getting strong typing for all non-UNIVERSAL > columns whether they like it or not,

Re: [sqlite] feature proposal - strong but dynamic typing

On Fri, Oct 30, 2009 at 7:14 AM, P Kishor wrote: > Actually, there can be one bad effect of Darren's suggestion, now that > I think of it, and that would be for those who don't care for strong > typing. They will end up getting strong typing for all non-UNIVERSAL > columns

Re: [sqlite] feature proposal - strong but dynamic typing

On Oct 30, 2009, at 10:14 AM, P Kishor wrote: > Actually, there can be one bad effect of Darren's suggestion, now that > I think of it, and that would be for those who don't care for strong > typing. They will end up getting strong typing for all non-UNIVERSAL > columns whether they like it or

Re: [sqlite] feature proposal - strong but dynamic typing

I believe I understand Darren's point (whether or not I care for them is another story). On Fri, Oct 30, 2009 at 2:22 AM, Roger Binns wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Darren Duncan wrote: >> But on a newer SQLite that implements the stronger

Re: [sqlite] feature proposal - strong but dynamic typing

Been watching this discussion go back and forth, and I'd like to weigh in. I'm generally a HUGE fan of strong typing, but this doesn't do it for me. To me, strongly typed means a compiler catches my type mismatches before the app goes out the door. In this case though, no matter what you do, a

Re: [sqlite] feature proposal - strong but dynamic typing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Duncan wrote: > But on a newer SQLite that implements the stronger typing support I proposed, > when that feature is active then columns with declared types like INTEGER/etc > would enforce that only values of that type are stored there, I

Re: [sqlite] feature proposal - strong but dynamic typing

Roger Binns wrote: >> In fact this support might even be easier as it may only require >> enhancements to >> the SQL parser, which would generate VM opcodes like for a CHECK constraint, >> unless further work is done to optimize for the presented cases, or to >> enhance >> semantics. > > It

Re: [sqlite] feature proposal - strong but dynamic typing

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Darren Duncan wrote: > I should point out, for people reading this thread, that it is very possible > to > have both the amount of type flexibility that SQLite provides and have strict > typing, at the same time. What I fail to understand with all

[sqlite] feature proposal - strong but dynamic typing

This email is a feature proposal for SQLite; I can rewrite it if desired. Ted Rolle wrote (in the "Late data typing ..." thread): > Doesn't dynamic data typing lead to bad data? > And proliferation of home-grown editing routines? > It seems that a strict data typing at column definition time