61–70 of 148 posts
Earlier quoted context omitted.
Seconded. The lateral join features in combination with the shortcut functions make it exceptionally easy to build backends with actual SQL, without compromising on ease of use.
Does that work also with Postgres-compatible backends like Bigquery et al ?
[flagged]
I think you should just keep a thing like this to yourself. It's attitudes like this that keeps people from daring to share their code with the world. What you might find ugly, others find beautiful. I'm actually pretty proud of this lib, and i enjoy my style of coding. Your comment doesn't change that, it just kills a lot energy.
In my head I’m having to cast these to an if to figure it out anyway - why not just write it like that to begin with?
Earlier quoted context omitted.
I think you should just keep a thing like this to yourself. It's attitudes like this that keeps people from daring to share their code with the world. What you might find ugly, others find beautiful. I'm actually pretty proud of this lib, and i enjoy my style of coding. Your comment doesn't change that, it just kills a lot energy.
It’s the giant nested ternaries that kill me. In nearly all circumstances I can think of (Terraform being a notable exception), ternaries could be replaced with an if/else if block and be far more readable. In my head I’m having to cast these to an if to figure it out anyway - why not just write it like that to begin with?
Earlier quoted context omitted.
I think you should just keep a thing like this to yourself. It's attitudes like this that keeps people from daring to share their code with the world. What you might find ugly, others find beautiful. I'm actually pretty proud of this lib, and i enjoy my style of coding. Your comment doesn't change that, it just kills a lot energy.
If you find it beautiful, who cares what I think? You aren't writing this for public opinions, presumably. I've also written a Postgres wire protocol implementation and a blog post on how to do so, which people are welcome to say "It's terrible" about if they wish.
The fact that you've also dabbled in this area could lead to a far more interesting discussion. Wouldn't mind seeing your blog post. Who knows, maybe I've already read it at some point?
btw the reason for extending eg Array is to make for a much better surface API when using the library.
Being able to do const [user] = await sql`...` leads to some very readable concise code.
B very careful with json and postgressjs, there are strange bugs. Also there are various gotchas on the edges with typescript. AFAIK the code uses a lot of regex and that breaks json in particular.
Looks neat. Is there a table generation / migration library included?
Earlier quoted context omitted.
If you're using parameterized queries, then you _have_ to use PostgreSQL's "Extended Query" flow, which is what most people would think of as a "prepared statement". This is hardly opinionated. But normally, you use an unnamed prepared statement and/or portal, which PG will clean up for you, essentially only letting you have one of those per session (what we think of as a connection). I agree that sentence didn't mak…
Thanks... I haven't got the mental energy to follow their code ATM but yeah, it seems weird to buffer a static query as a prepared statement if it's only going to be used once. Maybe that kind of goes with a Nodejs philosophy, though? It seems like an assumption that in most cases a static query will recur... and maybe that's usually accurate with long running persistent connections. I'm much more used to working in…
The benchmarks linked to don't compare PostgresJs to Prisma. That would be useful. Also the link text (Fastest full-featured node & deno client) should include the word benchmark, for those looking for one.
Here are two: