There does exist an experimental branch which introduces the concept of shell variables.
https://www.sqlite.org/src/timeline?r=shell-bindings The check-in comment describes the usage: "Add the ability to use bind parameters in the CLI. The new ".set KEY=VALUE" dot-command works to set bindings. Or use the "-Dkey=value" command-line option. Or use the built-in shell_bindings(k,v) virtual table to set, delete, or changing bindings." Note: A bug exists when setting text/blob values via the shell_bindings virtual table. The bindvtabUpdate method fails to set p->len. Adding p->len = len resolves the issue. On Sun, Jan 20, 2019 at 1:15 PM <andrew.g...@l3t.com> wrote: > > I'm jumping into the middle of the conversation, possibly without seeing the > beginning, but from what I've seen so far, it seems to me that the key is > recognizing there are many tools in a programmer's toolbox. Each tool covers > a certain area of functionality really well, then there are areas where it > can be applied but with difficulty, and then the rest is off-limits for any > serious applications. There is considerable overlap between the > applicability of different tools, so you get to pick your favorites. But you > have to be willing to incorporate additional tools when you get to the limits > of comfort for your favorite tool. > > However, instead what I often see is people trying to expand the scope of > their favorite. Sometimes this is the right choice, but usually it is not. > It takes considerable experience and good taste to be able to wisely judge > the difference and to chart a roadmap that legitimately enhances tools in a > way that justifies the cost to maintenance, documentation, ease of learning, > and so forth. I know I've been on the wrong side of this many times, but I > try to learn from my mistakes. > > SQLite is a special sort of tool in that it expressly acknowledges its > limitations, and it lets those limitations be its strength. I mean, "Lite" > is right there in the name. The idea of having a larger number of more > limited tools, with a stronger focus on interoperability, is a very powerful > and transformative engineering mindset and is central to the Unix design > philosophy (which, by the way, is often at odds with the Unix design > practice). The point of SQLite, in contrast to SQL servers, is that it be > embeddable in your application. Thus, SQLite has no need to replicate the > capabilities already present in every reasonable programming language. > Namely, variables. > > I do see a valid objection earlier in the thread: the SQLite shell. It > indeed lacks variables, though they can be emulated with temporary tables. > This is what I was talking about in the first paragraph. It's possible to > stretch tools beyond their core competency, but it can be difficult, so > you're better off letting other tools fill the gaps. But when you're using > the SQLite shell, that's not really a good option. You can let the SQLite > shell be the backend to a shell script, but you're not going to want to call > it more than once or twice per complete run of a program. > > So rather than discuss adding variable declarations to SQLite, maybe we > should be talking about adding variable declarations to the SQLite shell. > Please don't think I'm making a serious proposal. Instead it's just for the > sake of argument. Consider what would come of doing that. We'd be taking > the SQLite shell in the direction of becoming a programming language unto > itself, complementary to yet distinct from SQLite. Once the SQLite shell > gets variables, there would also be clamor for loops and conditionals and > function declarations and fine-grained I/O and so forth. That would be cool, > I suppose. And then, once all that is implemented, why not migrate the new > functionality from the shell into SQLite proper? But, umm, don't we already > have dozens or hundreds of programming languages to choose from? Does SQLite > really need to compete in that arena? > > Instead, here's what I think. SQLite is extensible by virtue of being > embeddable; it can be embedded in a wrapper that expands its capabilities. > Furthermore, the sources are maximally open and free, including the Lemon > parser. If you want to add new syntax to SQLite to ease its integration with > another programming language, start by duplicating and extending its parser > to recognize variable declaration and usage. The output of this new parser > would be plain-Jane SQLite SQL, augmented with all the necessary variable > declarations, statement compiles, parameter bindings, statement steps, column > extractions, error checks, and so on needed to make it happen. > > So, figure out exactly what you want the new syntax to look like, and write a > lot of sample queries in the updated language. For each example, write the > equivalent C code. Then, it will be your task to make a parser that knows > how to translate the former into the latter. Or more realistically, into > data structures that can be fed at runtime into the latter, having the same > net result but without the need to call a C compiler in the middle. > > People can then choose to use this wrapper around SQLite wherever it suits > them. > > One good place to do so would be an enhanced shell, which can be forked from > the original in order to spin up development quickly. > > Another would be in new language bindings, though it will be interesting > finding ways for the augmented parser to relate the variables in its string > input with variables present in its host environment. For languages like > Tcl, that will be easy. For languages like C, that will be impossible to do > automatically, and a manual association might be more difficult than just > using baseline SQLite. So instead, for C, keep the SQL variables inside a > dynamic data structure in which the host environment can peek and poke by > means of typed accessor functions, much like the current SQLite bind/column > API. > > All this is possible today, right now, with no need for any SQLite developers > to get involved. Anyone can start this task, anyone can write and publish > this code. > ------------------------------------------- CONFIDENTIALITY NOTICE: This > email and any attachments are for the sole use of the intended recipient and > may contain material that is proprietary, confidential, privileged or > otherwise legally protected or restricted under applicable government laws. > Any review, disclosure, distributing or other use without expressed > permission of the sender is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies without reading, > printing, or saving.. > _______________________________________________ > 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
