Without query translation you won't be able to do much date querying since date formatting and getting now() are very different in postgres and sqlite.
Also, sqlite doesn't support INTERVAL which I personally use heavily in postgres.
Curious how the author plans to deal with this since they mentioned they're interested in supporting BI tools that presumably wouldn't issue sqlite queries if they think they're talking to postgres.
Postlite author here. Patrick DeVivo mentioned using BI tools against Postlite, which sounded really interesting, but I think you're right. Those tools are going to heavily rely on dates which will not translate well between Postgres & SQLite.
I don't have any plans for query translation except for some basic client startup query handling (e.g. SET, SHOW). Postlite is really just meant as a thin shim to allow GUI tools to work remotely on SQLite databases.
Also, sqlite doesn't support INTERVAL which I personally use heavily in postgres.
Curious how the author plans to deal with this since they mentioned they're interested in supporting BI tools that presumably wouldn't issue sqlite queries if they think they're talking to postgres.