emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 3d38d1d: Add sqlite3 support to Emacs


From: Po Lu
Subject: Re: master 3d38d1d: Add sqlite3 support to Emacs
Date: Sun, 12 Dec 2021 12:46:02 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Richard Stallman <rms@gnu.org> writes:

> I don't know anything technically about sqlite3, so I can't begin
> to think about how to implement this, and I'm not sure what your
> suggestions really mean.

Basically, SQLite has the ability to load extensions (in the form of
shared libraries) at runtime.  But it doesn't provide a mechanism to let
programs determine whether an extension is acceptable before loading it.

Even worse, SQLite is under the public domain and not the GPL, so it is
legally permissible to create proprietary extensions.  The developers of
SQLite also maintain proprietary extensions for database compression and
encryption, both of which can be loaded through the mechanism currently
present in Emacs.

For more technical details, you can look at the following web page:
https://www.sqlite.org/loadext.html.  It should work from any browser
without JavaScript.

> What I do know is this: the crucial question is not what name that
> symbol should have, but rather, Which programs need to define it?
> Are you proposing to modify the free plug-ins to define this symbol,
> and make sqlite3 itself check for it?

No, I'm proposing to modify the free plug-ins to define this symbol, and
then to make Emacs to check for it before telling SQLite to load the
plugin.  It would work the same, and it'd also be much easier than
modifying SQLite and having to maintain the modified version, and so on
and so forth.

> Can we make Emacs load the plug-in, and check for the symbol,
> then arrange for sqlite3 to talk with it?

That's not possible, but we can check the .so file of the plugin for
such a symbol before telling SQLite3 to load it.

> We would need to prevent sqlite3 from loading plug-ins itself.
> But I think that all designs require some sort of change to
> sqlite3, because what it's designed to do is not acceptable as it stands.
> I see no way around the need to change sqlite3.

We could also remove the ability to load SQLite extensions from Emacs.

Thanks.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]