This makes it possible to correctly link against the system sqlite. Also, don't
use defers with log.Fatal() since they won't be run on exit.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>
Building with -tags libsqlite3 used the sqlite3.h from the system but the go
compiler will compile all *.{c,h} files in the same direcory:
"When the Go tool sees that one or more Go files use the special import
"C", it will look for other non-Go files in the directory and compile
them as part of the Go package. Any .c, .s, or .S files will be compiled
with the C compiler." (https://golang.org/cmd/cgo/)
So if users actually want to link against the system sqlite3 we should make
sqlite3-binding.* a noop.
Signed-off-by: Christian Brauner <christian.brauner@canonical.com>
The sqlite3_backup_finish() function never fails, it just returns the
error code from previous operations. Previously if it returned an
error, the finalizer wouldn't be unset and sqlite3_backup_finish() would
be run again on an already-finished backup. This results in a
double-free and often segfaults.
The error handling is described in more detail in the "Error handling"
section of https://www.sqlite.org/backup.html.
Does INSERT, then SELECT on the inserted rows (in-memory database).
The purpose of all these is to cause activity so there will be trace
messages to display. Trace message formatting is included
(a useful format, with explanations).
Also change type of EventCode to uint32 so adding AutoCommit
is "free" = does not enlarge the TraceInfo struct.
32 bits are more than enough, since only 4 (four) are used now.
The package is useless without cgo, but Go 1.7 will happily build it
since doc.go is a pure-Go file, even if CGO_ENABLED=0, like when
cross-compiling.
This is particularly problematic since the package is usually imported
for its side effects, and users would successfully build a broken binary.
Workaround golang/go#16981
Yasuhiro Matsumoto