From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: sqlite3 Date: Sun, 12 Dec 2021 05:21:48 +0100 Message-ID: <87bl1mihb7.fsf@gnus.org> References: <87tufmjyai.fsf@gnus.org> <87sfv5ljxn.fsf@gnus.org> <8735n5leza.fsf@gnus.org> <837dch1qox.fsf@gnu.org> <87ee6odu65.fsf@gnus.org> <83h7bjye0b.fsf@gnu.org> <87sfv360np.fsf@gnus.org> <83lf0vw6sg.fsf@gnu.org> <87k0gd1cl3.fsf@gnus.org> <83zgp8svkw.fsf@gnu.org> <83ilvvqwu8.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31332"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 12 05:23:03 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mwGO6-0007tK-A6 for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Dec 2021 05:23:02 +0100 Original-Received: from localhost ([::1]:50268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwGO4-0007hw-EU for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Dec 2021 23:23:00 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwGN6-00071O-4X for emacs-devel@gnu.org; Sat, 11 Dec 2021 23:22:00 -0500 Original-Received: from [2a01:4f9:2b:f0f::2] (port=33962 helo=quimby.gnus.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwGN3-0003O5-9K; Sat, 11 Dec 2021 23:21:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=7pHA4iJdDy37tDMfUczpmYkVcG0+hVnWGYpfkIG1toY=; b=Hgi5WoNlGOgarsiLcd9SjMDG6t ZcnzMrbrBSJjB9NCe6airONCz79n2ypvs+2TXOQEzTzhRcEtRVaMymv0b4IKoaSLpoSHbxfflFswN IclwW9OmNQ656PjNVcJpynHm3RR1QDocG9jcxu708tfrXr2IgvQouUzPqqHPQAaqXEEQ=; Original-Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mwGMv-0001Y9-Su; Sun, 12 Dec 2021 05:21:52 +0100 X-Now-Playing: Shopping's _Consumer Complaints_: "We Say You Pay" In-Reply-To: <83ilvvqwu8.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 11 Dec 2021 12:06:55 +0200") X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:4f9:2b:f0f::2 (failed) Received-SPF: pass client-ip=2a01:4f9:2b:f0f::2; envelope-from=larsi@gnus.org; helo=quimby.gnus.org X-Spam_score_int: -35 X-Spam_score: -3.6 X-Spam_bar: --- X-Spam_report: (-3.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:281735 Archived-At: Eli Zaretskii 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 '=C3=B3 < =C5=BA'). 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. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no