The SQLiteConn.RegisterAggregator implementation was defined in
sqlite3_trace.go file, which is guarded with a build constraint. This
change simply moves RegisterAggregator to the main sqlite3.go file,
and moves accompanying unit tests.
The rationale for this move is that it was not possible for downstream
using packages to use RegisterAggregator without also specifying (and
notifying the user) the 'trace' build tag.
See https://www.sqlite.org/vtab.html for more details.
This work was started from
https://github.com/gwenn/gosqlite/blob/master/vtab.{c,go} and adds:
- Porting the API to go-sqlite3 APIs.
- Support for >= Go 1.6 without requiring the `cgocheck` flag to be changed.
- Filling out the unfinished callback functions for the `Vtable` struct.
- A simple `Context` API layer for ease of use when adding modules.
Tests are included.
The semantics of sql.Tx.Commit impose that the transaction is
finished and cleaned up by the time the driver's Commit function
returns. However sqlite3 leaves the transaction open if COMMIT
fails due to an SQLITE_BUSY error, so *we* must clean it up.
Closes#184.
The cgo pointer passing rules forbid passing a Go pointer to C if that
pointer points to memory containing other Go pointers. This is true
even if the Go pointer is converted to uintptr.
This change fixes the code to use a handle instead, and to look up the
handle in the callback function.
In Go 1.6, the cgo checking rules are more precise when they see an
address operation as an argument to the C function. When you pass &v[0]
to a C function, the cgo check just verifies that v itself does not
contain any pointers. When you write `p := &v[0]` and then pass p to
the C function, the cgo check is conservative: it verifies that the
entire memory block to which p points does not contain any pointers.
When the bind function is called by code that passes a slice that is
part of a larger struct, this means that the cgo check will look at the
entire larger struct, not just the slice. This can cause a surprising
run time failure.
Avoid this problem by rewriting the code slightly to pass &v[0] in the
call to the C function itself.
In particular this fixes the tests of github.com/jmoiron/sqlx when using
Go 1.6.
Previously, the timezone information for a provided value was discarded
and the value always stored as in UTC. However, sqlite allows specifying
the timezone offsets and handles those values appropriately. This change
stores the timezone information and parses it out if present, otherwise
it defaults to UTC as before.
One additional bugfix: Previously, a unix timestamp in seconds was
parsed in the local timezone (rather than UTC), in contrast to a unix
timestamp in milliseconds that was parsed in UTC.
While fixing that extra bug, I cleaned up the parsing code -- no need to
convert to a string and then parse it back again and risk a parse error,
just to check the number of digits.
The tests were extended to cover non-UTC timezones storage & retrieval,
meaningful unix timestamps, and correct handling of a trailing Z.
sqlite_omit_load_extension is a go build tag which behaves much like its
C counterpart SQLITE_OMIT_LOAD_EXTENSION
Signed-off-by: Jessica Frazelle <acidburn@docker.com>
A call now doesn't have to do any reflection, it just blindly invokes
a bunch of argument and return value handlers to execute the translation,
and the safety of the translation is determined at registration time.
When specified, changes the default locking at a tx.Begin.
Changelog (v2):
Add a testcase to ensure _txlock is properly handled.
Closes#189
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
mattn