• Aftersun

  • Das Boot

    Das Boot

    Very claustrophobic

  • Kiss Kiss Bang Bang

    Kiss Kiss Bang Bang

    A lot of parallels with The Nice Guys. Christmas, LA, extravagent parties, two hapless “detectives” caught up in a mystery.

  • Spotlight

  • A new abbr using the excellent GitHub CLI to open any pull request associated with the current branch in the browser. I’ve mapped it to pr.

    gh pr view --web

  • TIL: Postgres version numbering

    I wanted to programatically compare postgresql versions on CI, local development, production, etc. You can get a version string with SHOW server_version (or SELECT current_setting('server_version')), but this can contain extra info. For example, on my development machine the value is 15.4 (Homebrew). As well as the string, there’s also a version number which seemed more useful.

    SELECT current_setting('server_version_num');

    On my development machine running postgres 15.4 this returns:


    That looked a little bit weird to me, so I looked into it further. It’s due to a change in the way postgres versions are numbered. Prior to version 10, the first two parts of the version number were the major version. So 9.5 and 9.6 are both major versions. A minor release would be something like 9.5.6 or 9.6.2. Since version 10, only the first number is the major version. 10.1 and 10.2 are both minor releases of version 10.

    When encoding this as an integer, the postgres team decided the two least significant digits would always be the minor version. The postgres versioning policy documentation explains more, as does this note from Alvaro Herrera. For versions 10 and above, we can split the major and minor version out like so:

      current_setting('server_version_num')::integer / 10000 AS major_version,
      MOD(current_setting('server_version_num')::integer, 100) AS minor_version;
     major_version | minor_version
                15 |             4