giteacraftr.sxr08/greenlight
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Adding 'Why not use an unsigned integer for the movie ID?' sub-section.

Browse Source
This commit is contained in:
Maxime Delporte
2025-11-07 11:06:35 +01:00
parent 0824a127b9
commit 490c3174ca
1 changed files with 19 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
README.md
View File

@@ -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 ```bash
pq: cannot insert multiple commands into a prepared statement 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. 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 ## Additional Information
### How different Go Types are encoded ### How different Go Types are encoded