Open jtarchie opened 4 months ago
Seems reasonable as an opt-in via a sqlite_geopoly
build tag.
Is that an approval or a recommendation?
Why not just set the flags yourself in your build?
CGO_CFLAGS="-DSQLITE_ENABLE_GEOPOLY" go build main.go
Just following the pattern of mattn go build flags.
Activation by tag of a feature can add useful Go functions for that feature. For example, some tags not only add “-D” but also provide a useful interface or functions. If you want CGO_CFLAGS, I won't reject it, but it won't provide that useful functions.
There is currently no geo-related interface in go-sqlite3, but it is possible that one may be added in the future.
As some tags only add "-D" wouldn't it be more consistent to add the tags covering all remaining SQLite features (even if they currently don't yet support a richer abstraction, as some do)?
Currently the only way to get Geopoly or Sessions enabled is to pass the environment variables down through the build?
Sqlite in standard amalgamation there is geopoly. It requires the
DSQLITE_ENABLE_GEOPOLY=1
compile time option. Would you accept a PR for this?