Jonathan Corbet <cor...@lwn.net> wrote: > So I'm messing with public-inbox a bit. I had to make the following > change before things would work on my Fedora system. (This is with > v1.0.0). > > The symptom was errors out of SQLite; it wouldn't pass "make test" much > less work properly. Some digging turns up this: > > If SQLite is built with the SQLITE_ENABLE_UPDATE_DELETE_LIMIT > compile-time option then the syntax of the UPDATE statement is > extended with optional ORDER BY and LIMIT clauses as follows > > Evidently, Fedora does not enable that option.
Odd; I didn't know about that option and don't know if there's performance implications for this. So with your patch, is everything else good on Fedora? > Now, I assume that LIMIT is there for a reason; I've not even tried to > look at the schema that public-inbox uses yet. But I thought I would toss > this out there to see you thought. Perhaps what I really need to do is to > ask Fedora to turn that option on? Using LIMIT is probably just a habit of mine. > --- a/lib/PublicInbox/Msgmap.pm > +++ b/lib/PublicInbox/Msgmap.pm > @@ -57,7 +57,7 @@ sub meta_accessor { > $prev = $dbh->selectrow_array($sql, undef, $key); > > if (defined $prev) { > - $sql = 'UPDATE meta SET val = ? WHERE key = ? LIMIT 1'; > + $sql = 'UPDATE meta SET val = ? WHERE key = ?'; `key' is the primary key anyways, so it should be fine to remove LIMIT, there. Will apply. > $dbh->do($sql, undef, $value, $key); > } else { > $sql = 'INSERT INTO meta (key,val) VALUES (?,?)'; -- unsubscribe: meta+unsubscr...@public-inbox.org archive: https://public-inbox.org/meta/