Show HN: pgcmd – An alternative to psql with JSON output
github.com
github.com
But Perl/Python/Ruby are very likely to be present on more number of systems (Windows being an exception). Why aren't more of these utility tools written in Perl/Python/Ruby?
But anyway even if your OS ships with perl/python/ruby installed by default (and also the right version) it probably doesn't ship with whatever Postgres library they're using so you'll still have to deal with extra dependencies anyway. And talking about Windows, installing node tools on Windows with npm is on the whole much easier than doing the same with Python/Perl/Ruby, so there is that.
If you want to make an argument that it should have been written in some language that easily compiles down to a single binary you can just download and run, then perhaps people would agree with you. But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.
OSX comes with Ruby and has for ages, although I think that's being phased out.
But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.
Node has been notoriously difficult to get running on FreeBSD, for instance. Patches were submitted and just sat on by the maintainers. Something like Perl/Python/Ruby let you target a POSIX-ish system easily, Javascript does not (case in point: electron).
I mean it's probably as simple as the person writing it being most familiar with JavaScript. There are a LOT of javascript developers who have never used perl/python/ruby before. They're not going to learn another tool just to write the tool they want.
From a technical perspective, node also has much platform support (notably on windows) than perl/python/ruby.
Arguably writing command line tools in Node.js has similar problems (8? 10? 12? 12.9?) though it has the advantage that not having a baked in version into your OS distribution means you have to install one yourself (which hopefully will match).
I think Go is a better choice for this type of thing as the end result is a copy-and-run-anywhere staticly linked binary.
Seen through a different lens, it's actually a compliment.
The poster sees the utility in the tool, even though it's not built on one of the poster's preferred platforms.
But the great thing is that the OP shared the source code on Github, so it can be ported to other platforms... if one is motivated enough to do so.
Isn't this required by package managers of all languages? pip/compose/gems all require internet access.
If you're doing the processing with jq and don't want to install any other tools than that, a jq csv -> json script should be about 10 lines.
TL;DR: CSV brittle, do not want.
But in this case you're not messing with some arbitrary CSV, you're generating it yourself right before converting into another horrible format. Slightly better.
$ psql -P pager -nqtc "select row_to_json(pg_database) from pg_database where datname = 'template0'" | jq
{
"datname": "template0",
...
"datacl": [
"=c/postgres",
"postgres=CTc/postgres"
]
}For example:
$ psql dbname -tAc 'SELECT json_agg(some_table) FROM some_table'
That will produce a valid JSON if you ever need to pipe it to another command. And I'm sure, psql will do the job a lot faster than node.By the way, you should not underestimate the built-in psql power and postgresql's json capability. Postgresql's JSON power rivals that of other JSON based No-SQL databases.
https://stackoverflow.com/questions/24006291/postgresql-retu...
SELECT json_agg(row_to_json(*))
work? select array_to_json(array_agg(row_to_json(t))) from (select * from name) t
seems to work... console.log(JSON.stringify(rows, null, 2));
So what’s the point?I find this is rampant in the Node community - For any small feature, rather than making a PR or suggesting changes to the original module (maybe via an option), the goal is to create a new library.
I feel what the Node community doesn't realize is that this creates a dependency hell where I can't run my programs which were running a week back, by pulling in the latest libraries.
Another example I came across recently was redux-thunk[0], which is used practically wherever redux is used. All it does is add a callback!
This is entire code of redux-thunk library!
function createThunkMiddleware(extraArgument) {
return ({ dispatch, getState }) => next => action => {
if (typeof action === 'function') {
return action(dispatch, getState, extraArgument);
}
return next(action);
};
}
const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;
export default thunk;
[0]: https://github.com/reduxjs/redux-thunkYou misunderstand the dynamic here. In the Node community you get bragging rights for how many “libraries” you have written and how many times they have been downloaded (99.99% of which will be by automated build systems, usually without the end user even being aware of any individual libraries except at the top level). These entangled dependencies are the entire point.