SQLite Forum


4 forum posts by user jklowden

13:49 Reply: Bug when converting string to boolean? (artifact: ac20f30109 user: jklowden)

SQLite3 does not have a boolean type. It has NULL, BLOB, TEXT, INTEGER, and REAL

Hmm, is NULL a type? It's a value in a ternary logic system. It's a marker for missing information. But it's not type.

It's definitely not a value, despite the common use of "NULL value". It's a nonvalue, the absence of a value. It's a property of a place where a value would otherwise be. That's why columns are declared with a type and NULL or NOT NULL: two distinct attributes of the attribute.

You can't cast NULL to or from anything. You can try, and the syntax permits it. But nullity trumps all:

sqlite> select typeof(cast(NULL as int)) as hello;

SQLite's output here is shorthand, the product of inexpressibility. The first parameter to CAST is a value; because values may be missing, CAST accepts NULL in place of a value. (You cannot, for example, CAST(REAL as TEXT) because "REAL" is a type, and CAST wants a value.) The output of TYPEOF is a type, or would be, if type there was. But there is not; the missing value has no type.

What TYPEOF is really saying is that the output of CAST in this case, when combined with something else, will be treated as NULL. Forced by the syntax to provide a one-word answer, it couldn't (more honestly) say missing integer. But that's what it means.

13:27 Reply: Bug when converting string to boolean? (artifact: 491dc0553c user: jklowden)

In SQL, = means the same as == does in most programming languages

Not "most", not by a long shot. Off the top of my head, not Pascal, Fortran, Cobol, Lisp, or APL. Not to mention that most iconic of Unix languages, the Bourne shell.

You could be right about "most" languages consciously derived from C, but then that might be tautological: any language using "==" might, by that very choice, be consciously derived from C.

SQL was invented at IBM, and some of its conventions are traceable to IBM languages of the era. For example, the use of single quotes to denote string literals, and the practice of escaping an embedded quote by 'doubling ''em up'.

21:20 Reply: Generating documentation (artifact: 26fc3957c0 user: jklowden)

Thanks, Warren, that's very helpful. I fetched the sources and added a symlink for ../sqlite.

My mistake was apparently to follow the www2 link. Some reptilian part of my gopher brain (to mix metaphors) said, hey, Newark is closer than Dallas.

$ fossil clone http://www2.sqlite.org/cgi/docsrc sqlite-doc.fossil
Round-trips: 2   Artifacts sent: 0  received: 0
Error: not authorized to clone
Round-trips: 2   Artifacts sent: 0  received: 0
Clone done, sent: 548  received: 562  ip:
server returned an error - clone aborted

All the bits seem to be where they belong now. :-)

19:43 Post: Generating documentation (artifact: b67356bd45 user: jklowden)

I don't understand the directions for how to generate the documentation.

Whether I use fossil, or pull the snapshot, my procedure is to create a build directory, cd to it, and run ../configure && make. In neither case do I get a docs directory, as indicated on the documentation source page.

The instructions say,

Download and unpack the source trees for SQLite

Does that mean I cannot use the fossil repo? (I guess so, since the documentation system is in its own repository, which afaict cannot be cloned.)

The SQLite install should be in ../sqlite

Is that literally true? The parent of the build directory must be "sqlite"? Or the prefix must be "../sqlite"?

Edit the Makefile for your system

[Emphasis mine.] The Makefile means the one generated by configure? If so, I see no reference to TCLINC and TCLFLAGS, nor to a docs directory in configure.ac or Makefile.in.

Finally, step b. at the end says,

Set TH3= and SLT= to empty strings

Those variables also do not appear anywhere that I see.

BTW, the comments in Makefile.in say See the comment at the beginning of configure.in for additional information. I think that should be configure.ac these days.

Many thanks.