This is a more ridiculous symptom of bad library design than the filesystem trouble mentioned by the article. In the real world, executing most SQL statement c

This is a more ridiculous symptom of bad library design than the filesystem trouble mentioned by the article. In the real world, executing most SQL statement could be made to return a semi-useful integer according to simple and consistent rules (e.g. affected row count, -1 if there's no meaningful integer). But the official Go documentation https://golang.org/pkg/database/sql/#Result https://golang.org/pkg/database/sql/#Result makes it quite clear that the Go design committee decided to imitate a remarkably limited and inelegant MySQL function that returns the value of an auto-increment column, not even realizing that only a few statements have auto-increment columns to begin with. I'd call this a negative amount of design effort. LastInsertId returns the integer generated by the database in response to a command. Typically this will be from an "auto increment" column when inserting a new row. Not all databases support this feature, and the syntax of such statements varies. (Of course, MySQL's LAST_INSERT_ID() is only bad as a building block and inspiration for a general API; in SQL queries assumptions aren't a problem and overspecialized tools can be occasionally very useful)