Ask HN: SQL tooling: REPL-likes, Intellisense, etc.
I’ve gotten quite spoiled by the nodejs REPL and by TypeScript. I’m in love with the idea of sum-types. Threads over the years on HN about SQL have me constantly telling myself: there must be a better way to “live” SQL so that I feel like I’m having a more proactive dialogue with my db. I feel like I should be able to know, as I’m typing a query, what the semantic possibility space is for eg syntax completion / tablename / return type of object, before I have completed or sent a query.
I mostly use my “host” programming language or pgsql to write queries. Is there better tooling for this for either SQLite or PostgreSQL? I’m interested in moving my personal structured data into this format to make working with SQL feel more natural and interactive to me.
Surely this tooling exists. But surely the tooling is better than what I’m finding in my Google searches. Anybody have a killer setup for something like this?
Online is ok. One-time software purchase is ok. A working tool-chain of multiple tools is ok, as long as it results in a more real-time interaction with the existing real model of the db.
Any recommendations?
4 comments
[ 2.4 ms ] story [ 19.0 ms ] threadAdditionally, postgres's psql CLI supports an rc file, one you can use for awesome configs. Put some time into that as well.
——
Definitely interesting, but I get the sense that it will suffer from the same problems that most ORMs I have used experience. It looks similar to the experience of using ORMs in statically typed languages.
You might be able to achieve this vision in a transpiled language if you can cover exact semantic equivalence for the entire language. I’m skeptical that it is possible without a huge engineering effort by this library, though, because it is targeting multiple different “runtimes” eg dbs.
I’d love to see DB authors of popular DB engines introduce support for some other language to support querying the relational model more directly, though, things like the postgresql jsonb query format not withstanding.
That would not require any parity or expectation of parity with SQL. Maybe I’ll do some research to see if I can find any initiatives along this line. I’m just amazed that this space isn’t better built-out vs, say, Haskell, given the huge buy-in for relational DBs and the amount of time that SQL has been around.
Anyway, thanks for the links! Getting setup with that first one now.