configure option to disable call to sqlite3_enable_load_extension in spatialite

[MB]

I am using libspatialite on a system that ships with sqlite that doesn't include support for sqlite3_enable_load_extension.

Is there some configure option like ''--enable-minzip=no" to disable the call to this?

I understand I can link in my own version of sqlite. But I would like to use the version that's included in the system.

If I just comment out the call to sqlite3_enable_load_extension in libspatialite code, what feature/functionality would break?

Thanks,

--MB

[mj10777]

 Without the capability to load extensions, 100% of the features/functionality will not be available. 

The precondition to use an extension (which is what spatialite is) is to load it. 

Thanks,

--MB

[MB]

I am statically linking libspatialite.a, libgeos.a, libgeos_c.a in an application.

The application using uses SQL queries that use spatial functions (St_intersects etc) provided by spatialite.

There is no '.so' to be loaded. 

Why would that functionality require sqlite3_enable_load_extension?

[Brad Hards]

Hi,

 

If you don’t load the spatialite extension into sqlite, sqlite can’t use it. You can use those functions in C/C++, but not in SQL.

 

Are you possibly using some ancient version? I’m not sure how this can work with anything recent (that I’m familiar with).

 

Brad

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/db2fa74f-b249-449a-91bb-1b474b13384cn%40googlegroups.com.

[mj10777]

By loading the extension you are telling sqlite  to load a further set of SQL commands. Without this sqlite will return 'Command not found". 

[mj10777]

On Monday, 28 December 2020 at 22:33:53 UTC+1 Brad Hards wrote:

Hi,

 

If you don’t load the spatialite extension into sqlite, sqlite can’t use it. You can use those functions in C/C++, but not in SQL.

Since the functions also call Spatialite specific SQL functions, that too will not work.  

[MB]

I am statically linking libspatialite.a, libgeos.a, libgeos_c.a and libsqlite.a.

I am not linking mod_spatialite.a.  Nor have I built the .so versions.

Its a C/C++ application that uses sql queries that include st_contains() in the where clause and it is returning valid rows.  The application explicitly uses spatialite_alloc_connection and spatialite_init_ex.

I don't understand why sqlite3_enable_load_extension is needed for this. 

[mj10777]

On Monday, 28 December 2020 at 22:30:00 UTC+1 MB wrote:

Because that is how  sqlite works. 

Should a firm determine that external functions for security reasons should not be allowed, the the sqlite liib does not contain the logic to interwact with an extension. 

To make sure, I checked my android lib (where everything is in one gigantic lib) and load extension is also called there for each new connection. 

[MB]

Thanks @mj10777 for confirming that it is needed for correctness. I will have to use a compiled version of sqlite that includes support for sqlite3_enable_load_extension.

I was under the impression it was needed for 'stored procedures' but it looks like its needed for all functionality.

[a.fu...@lqt.it]

Just to bring this thread to some conclusion.

starting from the initial question:
libspatialite calls just once sqlite3_enable_load_extension(),
and this happens in the stored_precedure.c source.
if you comment out that call you'll then obviously risk to
get some unexpected malfunctions when using a stored
procedure. if you aren't interested in stored procedure
it's absolutely harmless.

a more detailed reply:
libsqlite3 has two subtly distinct modes for supporting an
extension module (as SpatiaLite is).

a) by calling SELECT load_extension('module-name');
this in an universal mode that you can use on any
possibile language, from SQL itself to Java, Python
and so on.
this SQL call works in two steps:
a.1) first libsqlite3 will attempt to locate and
load the extension module
a.2) then it will attempt to find a conventional
EntryPoint (a C routine) containing all the
code to be executed in order to correctly
register and initialize the extension.

b) by statically or dinamically linking the library
implementing the extension. this second option is
only avaible for C or C++ programs.
in this second case there isn't any need to locate
and load the extesione code, because it's already
linked to your program (statically or dynamically
is absolutely the same, it makes no difference).
what is required is just executing the EntryPoint
routine so to register and initialize the extension,
and exactly this is the intended scope of calling
spatialite_init_ex() immediately after establishing
a db connection.

final remark: using a libsqlite3 not supporting the
capability to dynamically load extensions never is
a good idea. any possible effort should always be
done in order to replace this defective component
with a "genuine" unconstrained libsqlite3.

bye Sandro