diff --git a/README.md b/README.md index a4df3fd..1b6c816 100644 --- a/README.md +++ b/README.md @@ -198,7 +198,7 @@ if err != nil { } ``` -Having multiple statements in the same call is supported by the **pq** driver, so long as the statements do not contain any placeholder parameters. If they do contain placeholder parameters, then you'll receive the following error message at runtime: +Having multiple statements in the same call is supported by the **pq** driver, _so long as the statements do not contain any placeholder parameters_. If they do contain placeholder parameters, then you'll receive the following error message at runtime: ```bash pq: cannot insert multiple commands into a prepared statement @@ -206,6 +206,24 @@ pq: cannot insert multiple commands into a prepared statement To work around this, you will need to either split out the statements into separate database calls, or if that's not possible, you can create a [custom function](https://www.postgresql.org/docs/current/xfunc-sql.html) in PostgreSQL which acts as a wrapper around the multiple SQL statements that you want to run. +### Why not use an unsigned integer for the movie ID? + +The first reason is that PostgreSQL doesn't have unsigned integers. Instead, it's best to align the integer types based on the following table : + +| PostgreSQL type | Go type | +|-----------------------|-----------------------------------------------------| +| smallint, smallserial | int16 (-32768 to 32767) | +| integer, serial | int32 (-2147483648 to 2147483647) | +| bigint, bigserial | int64 (-9223372036854775808 to 9223372036854775807) | + +The second reason is that Go's **database/sql** package doesn't actually support any integer values greater than 9223372036854775807 (the maximum value for an **int64**). It’s possible that a **uint64** value could be greater than this, which would in turn lead to Go generating a runtime error similar to this: + +```bash +sql: converting argument $1 type: uint64 values with high bit set are not supported. +``` + +By sticking with an int64 in our Go code, we eliminate the risk of ever encountering this error. + ## Additional Information ### How different Go Types are encoded