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

31–40 of 160 posts

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

#31

Post by justinsaccount »

psanford wrote: post #21
justinsaccount wrote: post #14

Earlier quoted context omitted.

It's not really pure go, it's transpiled using https://gitlab.com/cznic/ccgo Just about all the code looks like this: // Call this routine to record the fact that an OOM (out-of-memory) error // has happened. This routine will set db->mallocFailed, and also // temporarily disable the lookaside memory allocator and interrupt // any running VDBEs. func Xsqlite3OomFault(tls *libc.TLS, db uintptr) { /* sqlite3.c:28548:21…

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.

Nope, note their readme says:

These combinations of GOOS and GOARCH are currently supported

darwin amd64, darwin arm64, freebsd amd64, linux 386, linux amd64, linux arm, linux arm64, windows amd64

and if you look at their source tree https://gitlab.com/cznic/sqlite/-/tree/master/lib you can see they have

sqlite_darwin_amd64.go sqlite_darwin_arm64.go sqlite_freebsd_amd64.go sqlite_linux_386.go sqlite_linux_amd64.go sqlite_linux_arm.go sqlite_linux_arm64.go sqlite_linux_s390x.go sqlite_windows_386.go sqlite_windows_amd64.go

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

#33

Post by wvenable »

hactually wrote: post #15
sam0x17 wrote: post #11

> However, without generics, Go’s type system can only offer so much I was reading the whole article waiting to see this line, and the article did not disappoint. This is still the main reason I will stick with Rust or Crystal (depending on the use-case) and avoid Go if I can for the foreseeable future. Generics are just a must these days for non-trivial software projects. It's a shame too because Go has so much prom…

They're really not a `must`. What a silly comment - Docker and Kubernetes and substantial parts of Google wouldn't be classed as trivial. For the thousands of devs shipping non-trivial code, keep going!

There's plenty of non-trival code written in C as well. That's not a good argument for the benefit of a programming language. You can work around any limitation with enough work -- this article is a perfect example. It's an ugly solution to a simple problem but it works.

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

#34

Post by grantwu »

joppy wrote: post #23
grantwu wrote: post #20

I was really really excited when I saw the title because I've been having a lot of difficulties with other Go SQL libraries, but the caveats section gives me pause. Needing to use arrays for the IN use case (see https://github.com/kyleconroy/sqlc/issues/216 ) and the bulk insert case feel like large divergences from what "idiomatic SQL" looks like. It means that you have to adjust how you write your queries. And that…

Arrays are nicer for the IN case because Postgres does not understand an empty list, i.e “WHERE foo IN ()” will error. Using the “WHERE foo = ANY(array)” works as expected with empty arrays.

Works as expected? Wouldn't that WHERE clause filter out all of the rows? Is that frequently desired behavior?

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

#35

Post by shriek »

bitwize wrote: post #29
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…

> Why would someone author an ORM, painstakingly creating Go functions that just map to existing SQL features? The answer to this question lies in the assumption you make in this statement: > the one which every engineer already knows: SQL. Not every engineer knows, or wants to learn, SQL. I've met very competent engineers, SMEs over their particular system, who were flummoxed by SQL. And many more just want to work…

> Not every engineer knows, or wants to learn, SQL.

Which is bizarre cause you pretty much need some form of RDBs in most of the apps. And because of ANSI SQL, the syntax/concepts are relatively same on different databases too. No point in not making this investment.

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

#37

Post by erik_seaberg »

hactually wrote: post #15
sam0x17 wrote: post #11

> However, without generics, Go’s type system can only offer so much I was reading the whole article waiting to see this line, and the article did not disappoint. This is still the main reason I will stick with Rust or Crystal (depending on the use-case) and avoid Go if I can for the foreseeable future. Generics are just a must these days for non-trivial software projects. It's a shame too because Go has so much prom…

They're really not a `must`. What a silly comment - Docker and Kubernetes and substantial parts of Google wouldn't be classed as trivial. For the thousands of devs shipping non-trivial code, keep going!

Kubernetes does a lot of code generation to work around some of Go’s shortcomings.

https://cloud.redhat.com/blog/kubernetes-deep-dive-code-gene...

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

#38

Post by scrubs »

scrubs wrote: post #6

Talk about JIT on target article ... I'll play with this at the office to tomorrow. I've got plans for it

Hmm that was a compliment. Translating: talk about a just in time article (with respect to me) which targets the problem I was thinking about just today ... I'll look at applying it tomorrow ... Now fix your down votes to some net positive value. Geez!

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

#39

Post by crescentfresh »

> A big downside of vanilla database/sql or pgx is that SQL queries are strings

What's wrong with strings? The argument in the article is that they cannot be compile-time checked, but I'm confused as to the solution to that problem ("you need to write exhaustive test coverage to verify them"). Is this saying that if they weren't strings you wouldn't need test coverage?

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

#40

Post by bpodgursky »

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…

I get this, but personally I love using jOOQ because of how composable and dynamic query building is with a good query builder pattern. Adding optional filters, joins etc doesn't turn into a string-concatenation abomination; it's something. can do in native readable Java

(and then translating back to generated Java objects is also great compared the alternative of unpacking some generic result set, casting to the right type, etc)

Post reply on HN