The Golang Zero Value Trap: How pgx v5 Exposed Silent Corruption
10 months ago by codeinabox to c/golang
I don't do Go (thankfully). But that description reminded me of "A False Midnight", which is a Python story from almost 12 years ago (time flies).
The fact that these two stories concern Python and Go, the two supposedly easy and simple languages, are good examples of why such descriptors were always intellectual smell.
Makes me wonder what were legitimate uses datetime authors mentioned existed for if time: meaning if time is not None and also not a midnight in UTC. I would kinda understand for non UTC, and maybe there are uses for date libraries' internals, but other than thet it seems too arbitrary
The core bug was that they were reading from a map without checking if the map entry existed. Given a non-nil var m map[K]V, m[key] always succeeds (never panics). If the given entry doesn’t exist, it returns the zero value for the type, i.e. var v V. If V is a pointer type, accessing a field or method will panic (because the zero value is nil). If V is a struct or other value type, it can be used normally. That bug is on them. Any Go developer who isn’t a novice should know how maps and value types behave.
@programming.dev
This is a community dedicated to the go programming language.
Useful Links:
Rules:
go to feed...
@programming.dev
This is a community dedicated to the go programming language.
Useful Links:
Rules:
go to feed...
TL;DR; Some bit of Go (or at least a Go lib they're using) coerces NULL time values to 0, so they added logic later down the data pipeline to check for 0s and convert them back to NULLs.
The full context of the problem definitely sounds tricky, like I doubt I would have realized it during development, but that little bit of data coersion logic is a HUGE code smell, for me. Never would have passed review, in my book.
The author's takeaway seems to be "just cause you've fixed a bug doesn't mean that's the end of the story," which is valid, but the far more important takeaway for me is "don't compromise on best practices in data management." Like, in this case, they had a data model that leverages NULL (to indicate a "don't overwrite this field" scenario, and they fed it into something that doesn't support NULLs. They KNEW about this, and papered over it with a lossy data conversion, instead of actually implementing proper NULL handling for this conversion, or changing the data model to not require use of NULLs.
save