Incorrect type generated for `SMALLINT`

[maxwelldorliea]

Version

1.24.0

What happened?

When creating a table that includes a column of type SMALLINT, the generated model that represents the column's field as int32 instead of int16. This can lead to unexpected errors from the database.

Got

type Account struct {
        ID        string
        Userid    string
        Balance   float64
        Pin       int32
        Currency  AccountsCurrency
        Createdat time.Time
        Upatedat  time.Time
}

Expected

type Account struct {
        ID        string
        Userid    string
        Balance   float64
        Pin       int16
        Currency  AccountsCurrency
        Createdat time.Time
        Upatedat  time.Time
}

Relevant log output

No response

Database schema

CREATE TABLE IF NOT EXISTS accounts (
        id VARCHAR(80) NOT NULL,
        userId VARCHAR(80) NOT NULL,
        balance FLOAT DEFAULT 0.0 NOT NULL,
        pin SMALLINT NOT NULL,
        currency ENUM('LRD', 'USD') NOT NULL,
        createdAt DATETIME NOT NULL,
        upatedAt DATETIME NOT NULL,
        PRIMARY KEY(id),
        FOREIGN KEY(userId) REFERENCES users(id)
);

SQL queries

No response

Configuration

version: "2"
sql:
  - engine: "mysql"
    queries: "sql/queries"
    schema: "sql/schema"
    gen:
      go:
        out: "model"

Playground URL

https://play.sqlc.dev/p/486276076a4aae590e56c6a81de718232c89d551c51dfbcea042246b56f430a5

What operating system are you using?

Linux

What database engines are you using?

MySQL

What type of code are you generating?

Go

[andrewmbenton]

Thanks for reporting this. It would be a backwards-incompatible change, but might make sense.

This can lead to unexpected errors from the database.

What kind of error do you see or anticipate? A SMALLINT should scan into an int32 even though it wastes memory, right?

[maxwelldorliea]

What kind of error do you see or anticipate? A SMALLINT should scan into an int32 even though it wastes memory, right?

Yes, but let's take a case where at the application level there's no check to verify whether the field/column is not bigger than int16 and the user enters a number that is larger than int16 passing that to the DB will lead to an error or unexpected behavior.

[andrewmbenton]

The input case does make more sense. I'll submit a pull request for this since I see that we do use int16 for PostgreSQL. Seems like it's worth fixing even though you can work around this with a type override.