[eknkc]

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]

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]

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]

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]

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/GB5v...

[catlifeonmars]

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