Hey, this is really cool.
Suggestion: check out the Slonik library for Postgres. It encourages writing raw SQL using string template literals (i.e. sql`select foo from bar where zed = ${someParam}`). It also supports strong typing of results, but the programmer needs to create their own Zod validators manually to check this and get strong typing support.
Seems like this tool could essentially pre-create the types for any raw Postgres SQL statement?
I think this approach of using raw SQL is much better than a custom query builder like kysely, where half the time I'm just trying to translate the SQL that I know in my head to some custom, library-specific API. But the benefit of using kysely is the automatic typing support. Being able to use raw SQL and get query types "for free" would be amazing.
This is interesting. You seem to provide extra functionality besides the typescript types over libpg-query, like the walk function, right? I assume that's the reason these changes can't be easily merged into the main library and you chose to fork entirely.
As an aside, do you think it's possible to use your libraries to get the return type of an arbitrary postgres query, even if it's dynamic? I have a library that requires users to write the return type of queries manually always, and I'd like to automate that step.
The main reason I didn't contribute my changes via PR is I wanted a package without "deparse" support, which adds considerably to the install size. I also didn't want pre-compiled binaries for every supported platform to be published to NPM, preferring a postinstall script that only downloads the necessary binary. I don't know how the walk function would be received by the original maintainers, as I didn't ask.
> do you think it's possible to use your libraries to get the return type of an arbitrary postgres query, even if it's dynamic?
Yes it is. I've solved that exact problem in pg-nano. I use the `describePrepared` feature of libpq: https://github.com/pg-nano/pg-nano/blob/4cca3dbe6be609c479e4...
Well the question you saw coming (hopefully) - how does it compare to Prisma use cases?
One thing I really like about Prisma is only updating my schema and having migrations generated as the "diff".
Are those migrations still editable, out of curiosity? Oftentimes I'll want to have migrations add things that simply aren't possible with some ORMs (e.g. generated columns, which can't be schema'd in most ORMs).
The main thing holding me back from Prisma is precisely what you like about it - if the migrations are auto-generated and I can't edit them afterward, I won't be able to do what I need to.
You can edit Prisma migrations. They are plain SQL files with no magic.
question: we are using kysely.dev as postgresql query builder and porsager's postgres.js for high performance.. is this something that can complement our stack or something to replace it entirely?