Comment 2 for bug 911292

A database index with different keys is what is needed.

And going "forward" RPM needs the ability to create tables
for whatever purpose is useful without waiting a decade
for distros to be able to be able to accommodate what is
in fact an utterly trivial engineering change.

But you are correct in recognizing that the Nvra index is
special because it contains a parser on the keys. What is
usually done in database programming is called a join, and
then there would need to be an index for each of the elements
in the tuple of {N,E,V,R,A,DE,DT}, and then a join using several
more tables, and with patterns that could be applied to each of
the multiple tables independently, would be done.

This is equivalent to writing an SQL layer onto Berkeley DB, and so
a different implementation, using the stem of a pattern as a
partial retrieval key on a single Nvra (Nevradt} string is being
attempted, with the tuples concatenated to form a string against
which the pattern can be applied.

Short answer: At the moment the Nvra index doesn't contain the
values you want to apply patterns to. this is the primary flaw.

Whether that is done by changing the existing Nvra index, or by creating
Yet Another Name ofr a new index is less important. It will be much
easier to change the Nvra index than to add the logic to chosse whether
Nvra or Nevradt index is intended.

At some point pattens will ned to be applied to all tables, not just Nvra. But none
is using the existing pattern matching retrieval or proposing as RFE.