On 6/26/17, 11:48 AM, "drhsql...@gmail.com on behalf of Richard Hipp"
wrote:
> OK. I'll back out the change, then.
That’s definitely safer, it’s a super useful capability but needs to be applied
selectively.
OK. I'll back out the change, then.
On 6/26/17, Peter da Silva 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
On 6/26/17, Peter da Silva wrote:
> On 6/26/17, 11:15 AM, "drhsql...@gmail.com on behalf of Richard Hipp"
> wrote:
>> If you get the latest check-in (https://www.sqlite.org/src/info/trunk)
>> there is a new option
On 6/26/17, 11:15 AM, "drhsql...@gmail.com on behalf of Richard Hipp"
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
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.
On
On 6/26/17, 9:00 AM, "sqlite-users on behalf of Richard Hipp"
wrote:
> The "db nullvalue STRING" command lets you translate NULL values into the
> string value of your choice. But there is not (currently) a way to
On 6/26/17, Peter da Silva wrote:
> What’s the best way to handle NULLs out of band when walking the results of
> a query:
>
> $sqlite_db eval “SELECT * FROM table ...” array {
> ...
> }
>
> In other Tcl database bindings it’s common to return arrays
What’s the best way to handle NULLs out of band when walking the results of a
query:
$sqlite_db eval “SELECT * FROM table ...” array {
...
}
In other Tcl database bindings it’s common to return arrays containing possible
null values with NULL values simply unset, so `[info exists]` can
8 matches
Mail list logo