GNU bug report logs - #69320
30.0.50; Support keyword-based substitutions in sqlite

Previous Next

Full log

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

From: "J.P." <jp <at> neverwas.me>
To: 69320 <at> debbugs.gnu.org
Subject: Re: bug#69320: 30.0.50; Support keyword-based substitutions in sqlite
Date: Sat, 24 Feb 2024 07:04:32 -0800

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> neverwas.me> writes:

>> @@ -333,6 +338,7 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values)
>>  {
>>    sqlite3_reset (stmt);
>>    int len;
>> +  int kw_dex = 0;
>
> I think one way to support interspersed param types would be to maintain
> two separate indexes, e.g,
>
>      int pos_dex = 0;
>
>>    if (VECTORP (values))
>>      len = ASIZE (values);
>>    else
>> @@ -341,6 +347,7 @@ bind_values (sqlite3 *db, sqlite3_stmt *stmt, Lisp_Object values)
>>    for (int i = 0; i < len; ++i)
>>      {
>>        int ret = SQLITE_MISMATCH;
>> +      int j = (kw_dex ? kw_dex : i + 1);
>
> which would mean changing this to something like
>
>          int j = (kw_dex ? kw_dex : ++pos_dex);

Actually, nah. This is bogus in many cases. It seems my mental model of
how these specifiers map to value-binding indices was based mostly on
magical thinking. I didn't realize, for one, that anonymous (positional)
specifiers and named ones share the same index space. AFAICT, this means
iterating over supplied parameters twice is unavoidable if we want to
support this feature in full. I've attached an updated version that
demos this approach even though I'm not super keen on it. It's somewhat
wasteful and definitely more complex. If anyone out there knows of a
smarter way, please do indulge me.

If a less ugly solution doesn't come about, I suppose we could impose an
artificial limitation saying that an argument list must either be
entirely one style or the other (positional or named), and never the two
shall meet. On the one hand, there seems to be some historical precedent
treating this as the recommended usage [1]. On the other hand, opting
for such a "nerfed" implementation (like my initial patch) may feel like
a cop out. If so, then it's probably best to stick with the status quo
and not support named parameters at all.

[1] "While all these forms are allowed, it is expected that different
    users will use different styles at different times."

    https://www.mail-archive.com/sqlite-users <at> mailinglists.sqlite.org/msg05313.html

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-Recognize-keyword-template-specifiers-in-sqlite.patch (text/x-patch, attachment)]

Previous Next

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