[Proj] Use of SQLite
Greg Troxel
gdt at lexort.com
Mon May 21 09:13:14 EST 2018
A few comments:
proj needs to be portable, and that precludes shipping a sqlite3
binary file. Presumably the source code will contain either some text
file that is loaded as part of the build process, and binary packages
will have binary sqlite3 files? Or something else?
(Assuming source file at build time) It's unclear if you mean the
source file to be a sqlite3 db dump, and if that will be in the VCS,
or something else? There seems to be merit in having a simple csv
format in the source tree. But perhaps sqlite3 dump is the new
lingua franca.
(not entirely related) My impression is that the EPSG database is
non-Free, and I wonder if the "modified version" becomes free, or if
this is still an issue to resolve.
Have you thought about the minimum version? I am unclear how many
systems include sqlite in the base system, and at which versions. So
if proj were able to work with fairly old sqlite (even if you would
recommend that people have newer), that would be good. Basically,
from a packaging viewpoint, while newer is usually better, it's
preferred to have as few forcing functions in the dependency graph as
possible.
I don't entirely follow the notion of using some other db. The nice
thing about sqlite is that it's linked in and you don't need to
configure a db username and have a process running. Once you do that,
things are much harder and more fragile, and there are security issues
if the db doesn't default to listening only on localhost. But I can
see the idea that some might want this. One Option might be for postgis
to read the proj db at build time, and essentially shadow it, which
would involve a way to read out the db -- which would be nice to not
be in sqlite dump language.
More information about the Proj
mailing list