Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

So I tracked down the commit which introduced the "truncated page is fine" behaviour: $ fossil info 647e3b156e uuid: 647e3b156e32e37debd60b0079fc5a52bdc9b8c8 2009-03-28 06:59:41 UTC parent: 1c6521e53b846eec2e046b1e9c04c60658b8e0e8 2009-03-27 15:26:03 UTC child:

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

On 13 January 2017 at 22:59, David Raymond wrote: > My view is that the general thinking of the program here is simply: "just > don't make things worse." It can't help what pragmas (ie > ignore_check_constraints, writable_schema etc) others may have turned on > for

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

On Fri, 13 Jan 2017 11:17:11 +0800 Rowan Worth wrote: > I wonder if this is something sqlite could catch in normal operation > and return SQLITE_CORRUPT? Or are there reasons/history which would > render this conclusion inaccurate? Not without cost. In general, it's difficult

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

My view is that the general thinking of the program here is simply: "just don't make things worse." It can't help what pragmas (ie ignore_check_constraints, writable_schema etc) others may have turned on for their connections, or what sort of junk was there when it arrived. In its head it's