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
