3 ms·

So, to avoid checking for null, you'll check for `NullString.Valid` now? The string pointer is a part of the language. You can pass it around, expose as part of

by eknkc 4y ago

So, to avoid checking for null, you'll check for `NullString.Valid` now? The string pointer is a part of the language. You can pass it around, expose as part of a library etc. And it conveys the intent perfectly. I have no idea what is the issue here?

psanford 4y ago
The nice thing about the Null* type is they can reduce the number of allocations done on the heap and thus also reduce total GC your program needs to do.
- legorobot 4y ago
  I haven't thought about it that way! I've not hit the GC as a performance wall when it comes to accessing nullable DB values yet. Thanks for the insight.
  - throwaway894345 4y ago
    It's generally useful, not just in SQL. Any time you have a type that could be multiple things, you have to choose between a reference-based implementation (e.g., interfaces) or a tagged struct (a struct with a flag field that tells you what its runtime type). The tagged struct version is guaranteed not to allocate, while the interface version very likely will. Most of the time it will only matter if you're in a tight loop.
legorobot 4y ago
I think the idea is `sql.NullString` can be used to have a SQL NULL still be an empty string in Go (just avoid checking the `Valid` field, or cast to string -- no check necessary). It seems like the intent of a string pointer vs. `sql.NullString` is their goal with this type anyways[1]? In practice I've used a string pointer when I need a nullable value, or enforce `NOT NULL` in the DB if we can't/don't want to handle null values. Use what works for you, and keep the DB and code's expectations in-sync. [1]: https://groups.google.com/g/golang-nuts/c/vOTFu2SMNeA/m/GB5v3JPSsicJ https://groups.google.com/g/golang-nuts/c/vOTFu2SMNeA/m/GB5v...
catlifeonmars 4y ago
Sometimes you want a non-nullable string pointer. In Go, nullability and dereferencing are coupled under the same language construct (pointers).

by eknkc 4y ago

psanford 4y ago

The nice thing about the Null* type is they can reduce the number of allocations done on the heap and thus also reduce total GC your program needs to do.

legorobot 4y ago
I haven't thought about it that way! I've not hit the GC as a performance wall when it comes to accessing nullable DB values yet. Thanks for the insight.
- throwaway894345 4y ago
  It's generally useful, not just in SQL. Any time you have a type that could be multiple things, you have to choose between a reference-based implementation (e.g., interfaces) or a tagged struct (a struct with a flag field that tells you what its runtime type). The tagged struct version is guaranteed not to allocate, while the interface version very likely will. Most of the time it will only matter if you're in a tight loop.

legorobot 4y ago

I think the idea is `sql.NullString` can be used to have a SQL NULL still be an empty string in Go (just avoid checking the `Valid` field, or cast to string -- no check necessary). It seems like the intent of a string pointer vs. `sql.NullString` is their goal with this type anyways[1]? In practice I've used a string pointer when I need a nullable value, or enforce `NOT NULL` in the DB if we can't/don't want to handle null values. Use what works for you, and keep the DB and code's expectations in-sync. [1]: https://groups.google.com/g/golang-nuts/c/vOTFu2SMNeA/m/GB5v3JPSsicJ https://groups.google.com/g/golang-nuts/c/vOTFu2SMNeA/m/GB5v...

catlifeonmars 4y ago

Sometimes you want a non-nullable string pointer. In Go, nullability and dereferencing are coupled under the same language construct (pointers).