OK. I'll back out the change, then. On 6/26/17, Peter da Silva <[email protected]> wrote: > This is really a pretty major change. > > Our experience with the comparable options in Pgtcl and Speedtables is that > there is likely a lot of code that assumes that all array elements are set > in `$db eval “...” array { ... }` blocks that will error out with this > change. I don’t think I would be comfortable using this in existing code > without doing an extensive audit... and for third party packages getting > changes propagated upstream. > > Making it a per-call option allows new code to use it safely, without > impacting any other components that might be using the same database. > > On 6/26/17, 11:31 AM, "[email protected] on behalf of Richard Hipp" > <[email protected] on behalf of [email protected]> wrote: > > On 6/26/17, Peter da Silva <[email protected]> wrote: > > On 6/26/17, 11:15 AM, "[email protected] on behalf of Richard Hipp" > > <[email protected] on behalf of [email protected]> wrote: > >> If you get the latest check-in > (https://www.sqlite.org/src/info/trunk) > >> there is a new option on the "sqlite3" command called "-unsetnull 1" > which > >> causes "db eval" to work as you desire - by unsetting the array > elements > >> for NULL values. This option is off by default for legacy > compatibility. > > > > Could that be an option on the eval command rather than the db, so > that > > packages can safely use the feature on databases they don’t “own”? > > > > It is per-connection. > > The change is sufficient minor and obscure that 99.9% of packages > should work the same regardless of the setting. The only reason for > making it an option rather than the only way things happen is for the > other 0.1% of application where it really will make a difference. > > -- > D. Richard Hipp > [email protected] > > >
-- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
