emacs-devel
[Top][All Lists]
Advanced

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

Re: sqlite3


From: Lars Ingebrigtsen
Subject: Re: sqlite3
Date: Sun, 12 Dec 2021 05:21:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> A couple of issues that caught my eye while reading the code:
>
>  . Should we invoke encode_string_utf_8 with 2 last arguments Qnil,
>    and signal an error if the result is nil?  That would make sure we
>    were passed a valid UTF-8 string.  We could also use non-zero 3rd
>    argument, for speed.

Let's see...  it's these two?

   If HANDLE-8-BIT is Qt, encode eight-bit characters into single bytes
   of the same value, like the usual Emacs encoding does.

   If HANDLE-OVER-UNI is Qt, encode characters beyond the Unicode
   range into the same 4 or 5-byte sequence as used by Emacs
   internally, like the usual Emacs encoding does.

I think sqlite3 will give us whatever bytes have been stuffed into the
file, so I think Qt is the most useful values here.  (Unless I'm missing
something.)  That is, sqlite3 doesn't enforce the charset for the data,
but it does use the charset when interpreting the data (for instance, if
you select for 'ó < ź').

I have not read the documentation in detail on this issue, so if this is
mistaken, somebody please correct me.

>  . sqlite-load-extension expects a file name with an extension, but
>    that would leas to Lisp code conditioning on system-type to use the
>    correct extension.  Should we instead append the extension inside
>    the function?  Also, are SQLite extension modules usually installed
>    in some known directory, or using some PATH-style list of
>    directories?  If they are, we could perhaps use 'load-'-style path
>    variable?

The extension loading thing was added as an afterthought, and is perhaps
not vital in an Emacs context, so perhaps we should reevaluate the
inclusion of that function.

But to answer your question, a module is currently loaded by absolute
name, and is typically "/usr/lib/sqlite3/pcre.so" (on this Debian
system, at least), and comes from the sqlite3-pcre package.  But I think
there's a lot of different extensions floating around out there, so if
we decide to keep the facility, adding something PATH-like might be
nice, and figuring out the .so/DLL thing by itself might also be nice.

So we'd have (sqlite-load-extension db 'pcre), perhaps, instead of the
absolute file name.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

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