[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sqlite3
From: |
Eli Zaretskii |
Subject: |
Re: sqlite3 |
Date: |
Sun, 12 Dec 2021 09:10:04 +0200 |
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 12 Dec 2021 05:21:48 +0100
>
> 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.
The documentation says "UTF-8", and my reading of that is that
anything outside of that is likely to trigger "undefined behavior".
There's also a question of whether we, the Emacs project, want to
force using only valid UTF-8 in those interfaces.
A related issue is with encoding file names, which are also expected
to be in UTF-8. I don't know what will happen if a file name includes
eight-bit raw bytes, for example. At least in the Windows code in
sqlite3, which I did read, the result will probably be a failure to
access the file.
> 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.
OK, let's revisit this if and when we decide that
sqlite-load-extension will stay in Emacs. Right now, it looks there
are several non-trivial issues with it.
- Re: sqlite3, (continued)
- Re: sqlite3, Eli Zaretskii, 2021/12/07
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/08
- Re: sqlite3, Eli Zaretskii, 2021/12/08
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/09
- Re: sqlite3, Eli Zaretskii, 2021/12/10
- Re: sqlite3, Eli Zaretskii, 2021/12/11
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/11
- Re: sqlite3,
Eli Zaretskii <=
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/12
- Re: sqlite3, Eli Zaretskii, 2021/12/12
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/12
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/12
- Re: sqlite3, Eli Zaretskii, 2021/12/12
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/12
- Re: sqlite3, Eli Zaretskii, 2021/12/13
- Re: sqlite3, Eli Zaretskii, 2021/12/13
- Re: sqlite3, Eli Zaretskii, 2021/12/06
- Re: sqlite3, Lars Ingebrigtsen, 2021/12/06