On Apr 7, 2017, at 1:14 AM, Dominique Devienne <ddevie...@gmail.com> wrote: > > On Fri, Apr 7, 2017 at 5:02 AM, Charles Leifer <colei...@gmail.com> wrote: > >> Is it conceivable that this change could be rolled back? > > ...their rule is "use only the official shell via > scripts” and no C code
As one who just ported a shell script written as a wrapper around the sqlite3 executable to Perl + DBI because it had grown beyond the natural bounds of shell scripting, I have to ask “WHY???” Don’t misunderstand, it’s great that you have the option to write simpler scripts as sqlite3 shell script wrappers, but at some point, there really are benefits to moving to something more powerful. (In my case, it was largely to avoid paying the cost of calling sqlite3 thousands of times in a loop with near-identical SQL, whereas the Perl script keeps the conn open and calls prepare() a few times to avoid repeated SQL re-parsing. The Perl version probably runs a couple of orders of magnitude faster.) I also want to know how a systems administration organization centered around Unix shell scripting gets to 2017 without any awareness that command output formats occasionally change? That’s a perennial danger. I can get behind the “no C” rule, since that just buys a different pile of portability problems. You need a really compelling reason to write something in C. (SQLite itself has one of those good reasons.) But what’s wrong with Perl, or Python, or Ruby, or Tcl, or… ? They all have stable SQLite DB access libraries, often included with the base OS, since so many things depend on those scripting languages *and* SQLite. I haven’t moved all of my sqlite3 shell script wrappers to Perl + DBI, and I won’t be doing so. Sometimes that’s exactly the right way to go. My objection is to this apparent “only one right way to do it” mentality. C, shell, and your favorite scripting language are all the “right way” in some contexts. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
