The problem/use-case that the feature addresses

The user only wants to view the result of the intersection or union and does not want to store it.

Alternatives you've considered

I think the reasons for support are as follows:

  1. Unification at the API level, such as sinter/sunion
  2. Using lua to achieve the same function requires three commands, which is expensive.

Additional information

In this post, antirez explained that zinter/zunion can be replaced by z[inter/union]store + zrange + del: https://groups.google.com/forum/#!topic/redis-db/ku0bCxxcMis

Comment From: itamarhaber

Hello @yangbodong22011

Thanks for proposing this feature. I'd also add another consideration - writing to the keyspace to create temporary keys is a pattern I don't really like. Let's keep this open to get some community feedback.

Comment From: yangbodong22011

@oranagra @itamarhaber Are you interested in this ZUNION/ZINTER? If allowed, I will complete it (in fact there is already a version without added tests).

If this command is not urgently needed, please tell me what I can do for Redis? Or Redis plan. Maybe to complete the tasks in Milestone (https://github.com/redis/redis/milestone/10)?

Of course, about Plan, this is a larger topic, maybe we can discuss it in Slack?

Comment From: itamarhaber

I think this is a good addition completion, but let's get the @redis/core-team's approval on this.

Looking at the milestone is a good start - tackling the stuff there is definitely helpful :) We're working on sort of plan for the next months that we plan to publish once ready. Once that plan is out we can of course also discuss it (slack or anywhere).

Comment From: oranagra

I'm in favor. I see one of Salvatore's arguments was that the non-STORE version would lose the scores, but maybe it was before ZRANGE had the WITHSCORES argument? i suppose that if we do that we need the new commands to support all of ZRANGE mutations and arguments? i.e. <start>, <stop>, <min>, <max>, REV, BYSCORE, BYLEX, WITHSCORES, LIMIT. and we need to do the necessary refactory so that it doesn't cause lots of code cloning.

Maybe such a refactory should be combined with the effort to add STORE argument to ZRANGE, in which we want to have a single ZRANGESCORE with REV BYSCORE BYLEX arguments rather than many individual commands. see https://github.com/redis/redis/issues/678#issuecomment-670644182

Comment From: yangbodong22011

I see one of Salvatore's arguments was that the non-STORE version would lose the scores, but maybe it was before ZRANGE had the WITHSCORES argument?

This may not be the reason, because the zrange command supports the WITHSCORES option from the beginning, see here. But I have no good explanation.

i suppose that if we do that we need the new commands to support all of ZRANGE mutations and arguments? i.e. , , , , REV, BYSCORE, BYLEX, WITHSCORES, LIMIT. and we need to do the necessary refactory so that it doesn't cause lots of code cloning.

My current version implements the WITHSCORES option, the design syntax is as follows: Z[UNION|INTER] numkeys key [key ...] [WEIGHTS weight [weight ...]] [AGGREGATE SUM|MIN|MAX] [WITHSCORES]

Maybe such a refactory should be combined with the effort to add STORE argument to ZRANGE, in which we want to have a single ZRANGESCORE with REV BYSCORE BYLEX arguments rather than many individual commands. see #678 (comment)

I think a refactory is a good idea, but I think ZRANGESTORE with REV BYSCORE BYLEX arguments is not a simple implementation, because currently ZRANGEBYSCORE and ZRANGEBYLEX do not have a lot of code redundancy, and many places are actually different, for example: - zslParseRange and zslParseLexRange - zzlLastInRange and zzlLastInLexRange

So I think the code may be full of judgment conditions, such as:

if (byscore) {
     zslParseRange();
} else if (bylex) {
     zslParseLexRange();
} else {
     ...
}

Regarding Z[UNION|INTER] with REV, BYSCORE, BYLEX, LIMIT. I prefer to merge the version of WITHSCORES first, and then unify and refactor with ZRANGESTORE.