// the find
christophgil/bash_builtin_SQL_DB
Bash builtins for using Postgresql and SQLite SQL databases in Bash script
Two Bash loadable builtins, cg_psql and cg_sqlite, that run queries against PostgreSQL and SQLite inside the shell process instead of forking psql or sqlite3 for every statement. Results come back in a Bash array. It is aimed at scripts that issue thousands of small queries and pay the fork cost on each one.
- The speedup is structural: the database client library is linked into a shared object loaded with enable -f, so a query is a function call instead of a fork and exec. The 811s versus 1.3s figure for 10,000 SELECTs is mostly that process startup, which is exactly what gets removed, so the order of magnitude is believable even if the exact numbers come from one machine.
- Results go straight into an indexed array, with field and record delimiters set per call via -d. Multi-column output needs no cut or awk afterward.
- The two backends share bashbuiltin_databases.c and cg_bashbuiltin.h, so option parsing and array handling are written once. The -V flag lets a script feature-test the builtin before relying on it.
- It ships a compile script, a runnable example and a benchmark script, so the claims can be rerun instead of taken on trust.
- Results are silently capped at DEFAULT_MAX_RESULTS unless -l is passed. The README names the constant but not its value or what happens to rows past the cap. That produces wrong answers without an error, which is the worst failure mode for a data script.
- The usage example is sloppy: a stray quote, an unused result='' line, and no guidance on passing shell variables into SQL. Any script that interpolates a variable into the statement string is one unescaped value away from SQL injection, and the docs say nothing about it.
- The benchmark's psql row runs the CLI once per query, which includes connection setup. That is a worst-case baseline; a fair comparison would use a persistent psql session via coproc. The row is also labelled /usr/bin/pgsql, which is not a real binary.
- The shared object is tied to the libpq and sqlite3 versions and the platform it was built on, and the README hands that setup off to a separate dependencies file. It says nothing about Windows or about error reporting, including what the array holds after a failed query.