This cannot be determined programatically. The query generator stores an OP_Variable opcode when the SQL program needs to access the contents of an SQL parameter, and keeps track of the highest parameter number used, which determines the size of the parameter array.
Even if you were to examine the generated bytecode to determine which variables are referenced and check if the referenced variable has a value, this would still not answer your question. And you would be excluding any query that requires NULL to be bound to an SQL parameter. Mixing numbered and named parameters is a very bad idea. Either you care about the assigned indexes or you don't. SELECT ?, ?10, ?2, :AAA; SELECT ?, :AAA, ?10, ?2; The above queries are different in much more than the order of the values returned. -----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von test user Gesendet: Montag, 22. Juli 2019 14:36 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: Re: [sqlite] [EXTERNAL] Determining valid statement placeholders. I understand the problem, but I want my library to be able to detect the problem programatically. Currently if a user mixes index-based and key-based placeholders, the only thing a library using SQLite can do us run the query with unbound placeholders set to null (the SQLite default). Id like the ability to instead throw an error in this case. I think SQLite internally knows how many placeholders are in the query at parse time. My question is how can I get the data via the API, or if it would be considered to add a function to get this data? On Mon, Jul 22, 2019 at 12:29 PM Keith Medcalf <kmedc...@dessus.com> wrote: > > On Monday, 22 July, 2019 04:34, Enzo <contact.enz...@gmail.com> wrote: > > >It is not the same information. > > >I want to be able to determine "has the user bound all placeholder > >values with data?". > > >The user provides this as input: > > >query="SELECT ?, ?10" > >data={"0": "data-a", "10": "data-b"} > > >Note: This IS valid, as they have provided all data for placeholders. > > >Using the APIs you mentioned: > > >count=10 > >name(10) = "?10" > > >So according to the API, the indexes [1, 2, 3, 4, 5, 6, 7, 8, 9, 10] > >are placeholders in the query. > > >As you can see, only indexes [1, 10] are valid placeholders in the > >query. > > >So, as far as I can tell, it is not possible to get this from the > >API: > > >query="SELECT ?, ?10" > >valid_placeholder_indexes=[1, 10] > > >It is only possible to get this: > > >query="SELECT ?, ?10" > >maybe_placeholder_indexes=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10] > > The fundamental issue is that you are confusing POSITIONAL parameters > with NAMED parameters. ?nnn where nnn is numeric describe POSITIONAL > parameters, so in the query SELECT ?, ?10 you are using positional > parameter 1 and positional parameter 10. That implies that there are > 10 positional parameters. The fact that you are only using those > positional parameters sparsely (only using positional parameter 1 and > positional parameter 10) does not mean that you are using two > parameters, it means that you are using 10, but only referencing 2 of them. > > Said another way, you are declaring a function that looks like this: > > int stmt(a, b, c, d, e, f, g, h, i, j) > return a + j > > and expecting to be able to call it as > > z = stmt(1, 6) > > expecting some magic to know that the second parameter is really > parameter 10. > > https://www.sqlite.org/lang_expr.html#varparam > > There may be many positional parameters (like 999 in the default > build) and sqlite3_bind_parameter_count returns the "index" of the > greatest parameter number used in the statement. Having created 10 > parameters sqlite has absolutely no clue that you happen to be using > only parameter 1 and parameter 10. If you only needed 2 parameters > you should have only created 2, not 10. That is what NAMED parameters are > for. > > If you change from using positional (?) parameters to using named (:) > or > (@) what happens? > > select :1, :10; should only create 2 parameters named :1 and :10 ... > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
