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.bugs Subject: bug#54591: 29.0.50; sqlite-select returns blob result as multibyte string Date: Sat, 02 Apr 2022 14:59:21 +0200 Message-ID: <87v8vrljyu.fsf@gnus.org> References: <83h77jaof6.fsf@gnu.org> <87lewsakng.fsf@gnus.org> <83o81o93ak.fsf@gnu.org> <87a6d672xr.fsf@gnus.org> <878rso7iuu.fsf@flokut.localdomain> 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="29475"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 54591@debbugs.gnu.org To: Johannes =?UTF-8?Q?Gr=C3=B8dem?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 02 15:01:03 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1nadNG-0007QC-P8 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Apr 2022 15:01:02 +0200 Original-Received: from localhost ([::1]:43256 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nadNF-0005Os-DZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Apr 2022 09:01:01 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:33378) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nadMM-0005O3-1A for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2022 09:00:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:50928) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nadMJ-0007fl-1C for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2022 09:00:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nadMI-0003sQ-TE for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2022 09:00:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Apr 2022 13:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54591 X-GNU-PR-Package: emacs Original-Received: via spool by 54591-submit@debbugs.gnu.org id=B54591.164890437414832 (code B ref 54591); Sat, 02 Apr 2022 13:00:02 +0000 Original-Received: (at 54591) by debbugs.gnu.org; 2 Apr 2022 12:59:34 +0000 Original-Received: from localhost ([127.0.0.1]:44825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nadLp-0003r9-KR for submit@debbugs.gnu.org; Sat, 02 Apr 2022 08:59:33 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:48646) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nadLo-0003qw-EK for 54591@debbugs.gnu.org; Sat, 02 Apr 2022 08:59:33 -0400 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=+idr+XWcyK5V5lLSuBaD/NBbsaFDM4ILWKrtUc3U/PM=; b=TT5qBYCm3XzWDxr0HTlnvHPSpy 5ri/omZsAptWZoYHNQH0Lw4guwm0l4gtroeMymQbYERdtlPCMYu/XMrITkiX/v12A5FLTDusu3hK3 VceP79pwNtoFN6YLFZxr2/R6sWnBAKbfUoVJ6qbv8msKyf5xZxMoyx7npFqBflP5GZfo=; 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 1nadLe-0005LE-AZ; Sat, 02 Apr 2022 14:59:25 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEXxz7f67MnfpaF8 U1T///94Yh8VAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YEAgwpHAodBrQAAAGwSURBVDjLZZMBloMw CESBXiDkBIgX2NX7321nIObVt7zWqj8wA0lFGM7LefGaFfXSXXyIHJ8CuA0Tqzvlkx3nxZUD6XiD GKOWZTRAVdMRUkvUhz0A6XbMyvAuFXktUTssqxQzWOqnMyQBSk21xO2X6xSGogwPXcC9Kol6OGu5 A/gGCsnDzVYfsPUAVcPH5AkArSdVZNkzFGrMo/IHir3B0Blo3EL2GMdyNaOKFuFw3MtVZdCHjgXU l91Z7qFla5zLVQFBXoFwf5VSblRnVFiijxKPtbmBDUOhLJBRu7xAawPgItFWNkBVaCCPAHoEa1YZ DUaVBsDOYztGLJCxDpckK9XWNpD2CMAlMJ/Jb4ZyVRDAudBGAx6HSmEp5TAA9GwNXQC/nOdtwiN3 ULE0eIeM87Y4bwAKzkccK+6bEAAdWAEEGgFQ/9wUQal8AQaB9XSzpj5QpgEqWzXax3KB6xsg8BfY wNsk7c5q6CnFOeUCB8Ej7nh/PHYZDa706UOWRuiwDeBGpUbibGm2RDWC5keDxEnfoM5ZN4hEfWVA cG/t3BoV1z9XuWOD/Ep4g/xajvgDshheeTQhZhQAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMDQt MDJUMTI6NDE6MjgrMDA6MDCfhoJoAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTA0LTAyVDEyOjQx OjI4KzAwOjAw7ts61AAAAABJRU5ErkJggg== X-Now-Playing: Gilberto Gil's _Soy Loco por ti America_: "Soy Loco Por Ti America" In-Reply-To: <878rso7iuu.fsf@flokut.localdomain> ("Johannes =?UTF-8?Q?Gr=C3=B8dem?="'s message of "Fri, 01 Apr 2022 20:34:49 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:229262 Archived-At: Johannes Gr=C3=B8dem writes: > I might be misunderstanding the issue, but SQLite column types are more > like documentation than actual rules to be enforced, unless STRICT > tables are enabled. Yeah, you can put anything you want into TEXT and BLOB columns. What I'd like to see happening is that the Emacs interface here is predictable and convenient, and that makes my brain hurt a bit here. Let's take a TEXT column first. Currently, if you have the multibyte string "f=C3=B3o" and insert with "insert into ... (?)", we encode to utf-8 and put the bytes #x66#xc3#xb3#x6f into the database. Selecting from the database, we get the bytes #x66#xc3#xb3#x6f back, decode and return the string "f=C3=B3o". If you have a unibyte string containing the bytes #x66#xc3#xb3#x6f, we don't do anything with that, but insert the bytes as is. When selecting, we decode and return "f=C3=B3o", which is not what the user inserted. In this case, it would be nice to signal an error, but we can't, because we don't know that it's a TEXT column in the first place. Conversely, with BLOB columns, we would prefer to signal an error on multibyte strings, but we can't, because we don't know that it's a BLOB column. But we do the right thing with unibyte strings -- if you give it #x66#xc3#xb3#x6f, it'll put those bytes into the BLOB column, and when selecting, we do know that it's a BLOB column, so we could return the unibyte string #x66#xc3#xb3#x6f, and everything's fine. However, if the user wanted to insert the string "f=C3=B3o", they'll be getting #x66#xc3#xb3#x6f back and will probably be sad. Today, the semantics are at least predictable: We insert everything encoded to utf-8 (no matter whether using bound parameters or inside the string), and if the user wanted something binary in the BLOB they selected, they just have to call `decode-coding-string BLOB-RESULT 'utf-8' to get the binary data. Which I understand is confusing, because it's very confusing indeed. But it's consistent, at least. If we knew what the type of the column we were inserting into, we could be more helpful in the interface, but there doesn't seem to be a way to get at that information? > By the way, if you want to insert BLOBs in the query itself you can do > it like this, but I guess this doesn't need Emacs support, except maybe > a helper function for the conversion: > > INSERT INTO foo VALUES (X'deadcafe'); Yes, but that leaves the issue to the caller, and the issue about what to do when selecting is still unclear. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no