1. 24
  1.  

  2. 4

    lib/pq: An early Postgres frontrunner in the Go ecosystem. It was good for its time and place, but has fallen behind, and is no longer actively maintained.

    Latest release was 6 days ago: https://github.com/lib/pq/releases/tag/v1.10.3, so it seems that it is still maintained.

    1. 5

      The README explicitly says:

      This package is currently in maintenance mode. For users that require new features or reliable resolution of reported bugs, we recommend using pgx which is under active development.

      1. 8

        “In maintenance mode” does not mean that it is not actively maintained.

        1. 4

          I would argue that the statement “Maintainers usually do not resolve reported issues” does mean it’s not actively maintained.

          That being said, this is probably getting into the semantics of what “actively maintained” means. For me, it means there’s active development and that reported issues will be resolved, neither of which seem to be the case for lib/pq at the moment.

    2. 2

      Used gorm in the past and it was a bit rough to be honest… gorm v2 was a little better but I didn’t have a very pleasant experience. This looks very nice, thanks for sharing, will give it a try.

      1. 3

        We have a saying when someone is obviously annoyed at work: “Gorm?”

        It’s surprisingly effective at getting to the RCA of someone’s frustration!

      2. 2

        Scany adds some quality-of-life improvement on top of pgx by eliminating the need to scan into every field of a struct. However, the desired field names must still be listed out in a SELECT … statement, so it only reduces boilerplate by half.

        I personally don’t feel like that counts as boilerplate. But maybe someone with more expertise in SQL queries can tell me why using a SELECT * would be better than listing the fields. Or maybe I just don’t mind taking a little extra time to be explicit because I prefer it.

        And I don’t see the difference between writing the SQL statements in my Go code as strings and writing them in a SQL file and using code generation to generate Go code with the queries in…a string. I dunno, maybe I’m more allergic to code generation than the author.

        1. 2

          SELECT * means you’re getting an unbounded mess of all the columns, while listing them individually means you’ll both only get what you need, and your query will break if the table structure changes. It’s generally better according to the SQL book I read recently.

        2. 2

          I have a few queries that it has some trouble with, that I’ve left as strings. A few where I had to add some column aliases to make it happy, but it understands the vast majority of my crazy queries with CTEs and unions and subselects that I was worried about before I tried it. I’m very happy with it.

          I think a lot of what I like about it is naming all my parameters and it generating struct arguments. I was using sqlx and the NamedGet/etc functions and passing a maps of string to interface, but it’s not type safe, and sqlx doesn’t have Named varieties for all the query functions, which really annoyed me.