GNU bug report logs - #61151
30.0.50; sqlite-more-p is confusing

Previous Next

Full log

Message #20 received at 61151 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 61151 <at> debbugs.gnu.org
Subject: Re: bug#61151: 30.0.50; sqlite-more-p is confusing
Date: Sun, 29 Jan 2023 20:44:19 +0200

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Cc: 61151 <at> debbugs.gnu.org
> Date: Sun, 29 Jan 2023 19:20:30 +0100
> 
> On Sun, Jan 29 2023, Eli Zaretskii wrote:
> 
> >> However, sqlite-next seems to return nil once, but then it starts over.
> >
> > This should be easy to fix.
> 
> The documentation[1] also says: 
> 
>   SQLITE_DONE means that the statement has finished executing
>   successfully. sqlite3_step() should not be called again on this
>   virtual machine without first calling sqlite3_reset() to reset the
>   virtual machine back to its initial state.
> 
> So this would seems like prudent fix.

What is "this"?  Signaling an error after sqlite-next returns nil?  Or
something else?

> If we don't change the way the API works, then maybe the documentation
> should mention that the proper way to iterate over the results is a bit
> unusual. E.g.:
> 
> (let* ((db (sqlite-open))
>        (stmt (sqlite-select db "values ('a',0), ('b',1)" nil 'set))
>        (rows '())
>        row)
>   (while (progn (setq row (sqlite-next stmt))
> 		(sqlite-more-p stmt))
>     (push row rows))
>   rows)
> 
> And perhaps provide a function like sqlite-for-each that hides this
> peculiarity.

Let me think about this.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.