1. Psql comes with backslash commands that are implemented at the client level and not in the database. So you can't simply send `\dt` to the database. That will fail. The same is true for mysql as well (such as `\u`).
2. There wasn't a huge overlap in users who use Postgres and Mysql at the same time. Even for the minority that do, I tried to keep pgcli and mycli behave similarly so they can switch between them seamlessly.
3. The code complexity needed to support multiple database backends would make it hard for a newcomer to contribute to the project. This is just my guess and I don't have data to back this up.
4. I didn't think I could do a good enough job of maintaining parity with psql and mysql's default client if I had a universal client. I still don't have complete parity but it is close enough that users don't feel like their compromising a lot.
I'm happy you're taking on this challenge and I'll be glad to give you pointers on how the sql completion engine works in pgcli and mycli.
I found out about this from one of the core-devs of pgcli. He made it possible to embed pgcli inside ipython. We wrote a blog post about how to use this: http://pgcli.com/embedding-pgcli-in-ipython.html
Awesome projects, thanks!
I installed go 1.8, and then issued the prescribed command line. It tells me `# github.com/mattn/go-sqlite3 exec: "gcc": executable file not found in %PATH%`. This looks like a rabbit hole of unknown depth that I'd prefer to stay out of.
The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.
When using GNU SQL for a publication please cite:
O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.
Following that rationale, why doesn't any sane person cite Matlab, R, Tex or MS Word on their publications?
What would really make a difference in how we perceive the SQL CLI world would be an IPython-like interface – complete with syntax highlighting, tab-autocomplete menus, easy multiline backlog entry editing etc.
If you want to really make this usable here's what you need to add:
- usql -f foo.sql
- Allow @path/to/file.sql and @@path/to/relative/file.sql references
- Common syntax for referencing env variables in SQL (each DB's utilities have slightly different syntaxes so have to pick one)
- External transaction demarcation to ensure a set of commands get executed together (ex: psql --single-transaction)
- Some autocompletion (if you plan on this being used for interactive use)
Say you have a folder structure like this:
If script file resolution is not relative pathed to the parent, it gets very fragile as you must invoke the parent from a specific location, or, you have to hard code full pathes in your scripts (arguably even uglier).
(for certain large values of near).
If it is that you can even include Neo4j support.
Btw, it would be relatively straightforward to add support on your own. PRs always are welcome!