This fixes the problem where when building with gccgo, sqlite3.c is
overwritten, leading to a build failure.
An alternative would have been to move sqlite3*.{c,h} to a subdirectory,
but that seems to confuse the linker a fair bit and would just swap one
implementation-dependent issue for another.
Closes#20
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
Fixes the following error message on SmartOS:
$ go get github.com/mattn/go-sqlite3
In file included from /usr/include/stdio.h:37:0,
from go/src/github.com/mattn/go-sqlite3/sqlite3.c:8422:
/opt/local/gcc47/lib/gcc/i386-sun-solaris2.11/4.7.3/include-fixed/sys/feature_tests.h:366:2: error: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99"
Use the sqlite3_errmsg() API to retrieve more specific error
messages.
eg. Attempting to exec 'CREATE TABLE ExistingTableName (...)'
will now report 'table already exists: ExistingTableName' rather
than 'SQL logic error or missing database'
This commit introduces a new type 'ErrNo', implementing the error
interface. Constants for all sqlite3 error codes are provided
in the new source file "error.go".
By loading extensions this way, it's not possible to later load
extensions using db.Exec, which improves security, and makes it much
easier to load extensions correctly. The zero value for the slice
(the empty slice) loads no extensions by default.
The extension example has been updated to use this much simpler system.
The ConnectHook field is still in SQLiteDriver in case it's needed for
other driver-wide initialization.
Updates #71 of mattn/go-sqlite3.
The ConnectHook field of an SQLiteDriver should return an error in
case something bad happened during the hook.
The extension example needs to load the extension in a ConnectHook,
otherwise the extension is only loaded in a single connection in the pool.
By putting the extension loading in the ConnectHook, its called for every
connection that is opened by the sql.DB.
This commit introduces a new type 'ErrNo', implementing the error
interface. Constants for all sqlite3 error codes are provided
in the new source file "error.go".
sqlite3 documentation states sqlite3_column_blob could modify the
the content and recommends the "safest and easiest" policy is to
invoke sqlite3_column_blob() followed by sqlite3_column_bytes()
from: http://www.sqlite.org/c3ref/column_blob.html
SQLite3 stores timestamps very naively -- they're completely untyped,
and can contain any value. The previous implementation always inserts
values in the 'datetime' format, and returns an error when attempting to
extract a field with a different format.
Some legacy databases, unfortunately, were generated using the 'date'
SQLite3 function, which produces rows in the '2006-01-02' format. This
patch adds a special case so that these rows can be extracted without
error.
Original:
--- FAIL: TestInsert (0.00 seconds)
sqlite3_test.go:42: Failed to create table:%!(EXTRA *errors.errorString=unable to open database file)
With corrections:
--- FAIL: TestInsert (0.00 seconds)
sqlite3_test.go:42: Failed to create table: unable to open database file