Open danielrearden opened 2 years ago
Hi @danielrearden, this sounds very cool! Yeah, slonik-typegen is slowly moving in that direction already. It started by blindly accepting the pgdesc
results from psql
but over time it's had to do more and more static query analysis, mostly to figure out nulls. But null detection is far from perfect, and I've tried and failed a couple of times to improve it. Specifically, I want it it to be able to trace the "source" table for CTEs and views (and maybe even functions). Can pg-magic do that? I've also thought a little about the JSON idea you're describing so all of this sounds great. A couple of questions:
Also curious if it could help with #315
I wrote a small library for generating TypeScript types from Postgres queries using only static query analysis. There's a number of advantages of using static query analysis over the approach currently used by
@slonik/typegen
including:psql
coalesce
ornullif
There's also some pretty cool things we could do in the future, for example, providing very accurate types for JSON objects built using
json_build_object
or narrowing the types based onWHERE
conditions.There are, of course, tradeoffs as well. Namely, because static analysis requires us to effectively duplicate logic that's already handled by Postgres, there's a risk of human error and the possibility that we haven't covered every possible expression. However, I think the flexibility and simplicity of the approach outweigh the risks.
I actually wrote
pg-magic
with the hope that it could be used with@slonik-typegen
😅 Let me know whether you think it would be worthwhile to move in this direction!