You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Activity
andrewmbenton commentedon Jan 4, 2024
Thanks for reporting this. It would be a backwards-incompatible change, but might make sense.
What kind of error do you see or anticipate? A
SMALLINTshould scan into anint32even though it wastes memory, right?maxwelldorliea commentedon Jan 4, 2024
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
int16and the user enters a number that is larger thanint16passing that to the DB will lead to an error or unexpected behavior.andrewmbenton commentedon Jan 5, 2024
The input case does make more sense. I'll submit a pull request for this since I see that we do use
int16for PostgreSQL. Seems like it's worth fixing even though you can work around this with a type override.fix(codegen/golang): Use `int16` for MySQL `SMALLINT` and `YEAR`
fix(codegen/golang): BREAKING: Use `int16` for MySQL `SMALLINT` and `…
fix(codegen/golang): BREAKING: Use `int16` for MySQL `SMALLINT` and `…