Angus Pearson

Supporting hash tagged keys that have matching tags would be great. I think it'd be a bad idea to try and determine for *any* key if they're in the same...

> That being said, I consider removing the possibility of aliasing rm to rip more of a feature than a bug. I'd agree that you should know what you're actually...

Adding to this, it may make sense also supporting **hash tags** for those running a cluster of Redis servers https://redis.io/topics/cluster-spec#keys-hash-tags

So the `create` here is not a Redis command (so shouldn't be in https://redis.io/commands) and is instead part of the new Cluster Management tools that are built in to `redis-cli`...

The complexity for each different `LOLWUT` may also be different, depending on what it does and the args it takes... Perhaps it would be better to retract the "safe to...

I think it would be good to either give a time-complexity, or a quick note as-to why there isn't one. Some of those given above by @itamarhaber are certainly expensive!...

> A lovely co-worker pointed out that it's only for the response, this doesn't attach information to the query itself for observability purposes. According to the spec: > The RESP3...

> Maps represent a sequence of field-value items, basically what we could call a dictionary data structure, or in other terms, an hash. The theoretical datastructure 'hash' and 'dictionary' are...

I think some kind of protocol-level support for error checking is probably desirable, and ideally should allow for different ways of checking (e.g. checksums, MD5, etc.). I don't think that's...

One could also argue that checksums can already be supported, using the **attribute** type, as these can be returned surplus to what the client was expecting back, e.g. ``` |1...