Curious, why "set" command returns "OK" and not "true"? boolean is 1 byte and OK is 2 bytes
if complete rewritten, will redis be having boolean instead of OK?
Comment From: madolson
The original Redis protocol didn't contain a boolean response, so returning OK was just the decision that was taken. If we started from scratch returning a boolean doesn't really make sense either though, since it's not communicating any information, we'd probably return an empty response or something.
Given that, the behavior will likely never change in order to preserve backwards compatibility.
Comment From: hiqsociety
great answer. cant preserve backwards compatibility with other redis clients by getting a nil?
isnt it time to have a redis version that breaks compatibility?
Comment From: madolson
Someone could be checking for the OK value, so it's hard to say that starting at a given version OK was replaced by nil. Unlike a lot of other databases, we place very high value on backwards compatibility. It allows our users to upgrade without too much worry about breaking.
Comment From: hiqsociety
can u guys do upon connect, sending a versioning request for this? e.g. connect, new args parameter (version 1X) -> anything 1X will return nil instead of ok
Comment From: madolson
We probably could, but I don't think that is really worth doing for a byte. It would require a lot of client work for something that is tiny. If we end up with a lot of changes that would benefit from a new version, we might consider it.
Comment From: hiqsociety
it's actually 5 bytes. i did a return of nothing. not even the \r\n so that's quite a lot. the optimization in rps is around 10-17% improvement i guesstimate, both for client and server, there's 5 bytes lesser things to do.
Comment From: madolson
Yeah, but a tcp packet isn't free either. Going to close unless there is a specific ask to implement now.