Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How We Went All In on sqlc/pgx for Postgres and Go

brandur.org

Post reply on HN
Print view View original

111–120 of 160 posts

Re: How We Went All In on sqlc/pgx for Postgres and Go

#111

Post by Foobar8568 »

erdemozg wrote: post #110
Foobar8568 wrote: post #103

So they are using a full blown relational database to use it like they are reading files on a share. Amazing indeed. From the docs and online comments, SQLC doesn't support join. I am amazed by the number of comments and nobody point this out.

Can you provide some resources about the lack of support for joins in sqlc? Because I wasn't able to find in official documentation and actually there's a discussion on github containing queries with join statements: https://github.com/kyleconroy/sqlc/issues/213

Yes, I was about to reply to myself with a link to this issue as I couldn't see anything in official docs unless looking at the github issues.

https://github.com/kyleconroy/sqlc/issues/1157

Re: How We Went All In on sqlc/pgx for Postgres and Go

#112

Post by erdemozg »

Foobar8568 wrote: post #111
erdemozg wrote: post #110

Earlier quoted context omitted.

Can you provide some resources about the lack of support for joins in sqlc? Because I wasn't able to find in official documentation and actually there's a discussion on github containing queries with join statements: https://github.com/kyleconroy/sqlc/issues/213

Yes, I was about to reply to myself with a link to this issue as I couldn't see anything in official docs unless looking at the github issues. https://github.com/kyleconroy/sqlc/issues/1157

But it seems like this discussion is about the lack of support for null values in enum types in joins (not joins in general). Am I missing something?

Re: How We Went All In on sqlc/pgx for Postgres and Go

#113

Post by Sadzeih »

earthboundkid wrote: post #78
sk0g wrote: post #58

Earlier quoted context omitted.

JetBrains IDEs help with this actually. When I was working with Go, all SQL longer than one or two lines went into the package level sql.go file, each query being a multi-line string. If you preface it with a comment like `// language=PostgreSQL`, you get syntax highlighting for PGSQL. What's more, if you have databases configured in your IDE, it tries to cross-reference the tables, columns, etc, and validates the qu…

With Go 1.16, you can embed SQL files into your Go app instead of using a multiline literal. I actually am curious if a SQLC competitor should be written using embed + generics once generics drop in 1.18. I haven’t totally worked on what it would look like yet, but it’s an interesting idea.

I think generics will change a lot of the ORM space for go yeah. Will be interesting to see.

Re: How We Went All In on sqlc/pgx for Postgres and Go

#114

Post by sshb »

sa46 wrote: post #27

I agree whole-heartedly that writing SQL feels right. Broadly speaking, you can take the following approaches to mapping database queries to Go code: - Write SQL queries, parse the SQL, generate Go from the queries (sqlc, pggen). - Write SQL schema files, parse the SQL schema, generate active records based on the tables (gorm) - Write Go structs, generate SQL schema from the structs, and use a custom query DSL (prote…

> - Write custom query language (YAML or other), generate SQL schema, queries, and Go query interface (xo).

I've also tried to unify this approach with gRPC/Protobuf messages and CRUD operations: https://github.com/sashabaranov/pike/

Re: How We Went All In on sqlc/pgx for Postgres and Go

#116

Post by tgv »

throwaway894345 wrote: post #22
psanford wrote: post #21

Earlier quoted context omitted.

Being translated means it doesn't have the normal cgo calling overhead. It also means you can cross compile it for every platform that the Go toolchain supports without any external compilers.

OP mentioned that the pure-Go version is ~6 times slower, so the cgo calling overhead is clearly made up for by C. Also, I've heard that sqlite is the rare piece of C software that is actually bulletproof, so I don't think the pure-Go version can make the usual boasts about correctness and security in this particular case. Not needing extra external compilers is still a nice proposition, however.

Especially for portability/cross compiling.

Re: How We Went All In on sqlc/pgx for Postgres and Go

#117

Post by stayfrosty420 »

>ORMs also have the problem of being an impedance mismatch compared to the raw SQL most people are used to, meaning you’ve got the reference documentation open all day looking up how to do accomplish things when the equivalent SQL would’ve been automatic. Easier queries are pretty straightforward, but imagine if you want to add an upsert or a CTE.

How does this make sense? Most ORMs will give yo a way to execute raw sql which you marshal into a struct the way yo would with a lower level library.

Re: How We Went All In on sqlc/pgx for Postgres and Go

#118

Post by [deleted] »

marcus_holmes wrote: post #97
EB66 wrote: post #57

Earlier quoted context omitted.

> Working with SQL in X (any language) usually has a poor developer experience that is why ORM or query builders are popular. At least when it comes to Postgres, I don't understand why more developers don't create their own user-defined functions with PL/pgSQL. It's very a robust and powerful procedural language. In my opinion, ORM's like SQLAlchemy add a completely unnecessary layer of abstraction. ORMs might be con…

I did this on a recent project, and it worked really well. I had each function definition in its own .sql file, with a preceding "drop function" call, and a Makefile clause to run them all. Which meant managing versions was easy (coupled with migration .sql files). I also got to find out if any of my SQL was broken right up front, and testing the SQL was simple - call the function and check the return. I also defined…

[deleted]

Re: How We Went All In on sqlc/pgx for Postgres and Go

#119

Post by JulianMorrison »

Looks very similar to the annoyingly named "mybatis". I approve of the principle: SQL should be separated from code, because SQL needs to be written, or at least tuned, by someone with database expertise. There are often deeply subtle decisions on how to phrase things that affect which indexes get used and so on, and can make orders of magnitude difference to how quickly a query executes.

This is also why ORMs that write the query for you are unhelpful. You're stuck trying to control how a machine makes SQL.

Re: How We Went All In on sqlc/pgx for Postgres and Go

#120

Post by otabdeveloper4 »

fprog wrote: post #12

From the article: > I’ve largely covered sqlc’s objective benefits and features, but more subjectively, it just feels good and fast to work with. Like Go itself, the tool’s working for you instead of against you, and giving you an easy way to get work done without wrestling with the computer all day. I've been meaning to write a blog post about sqlc myself, and when I get to it, I'll probably quote this line. sqlc is…

> code generation, instead of e.g. reflection

"Hey man, we noticed there's not enough compiler in your compiler, so we made a second compiler for your compiler."

Post reply on HN