Didn't we get rid of merging minor compactions?

We did, but I think it's possible that we still run across these files when reading. The code does not create files starting with an 'M' anymore.

Should probably include an inline comment here, then, so we can just document it as a reserved due to its use in the past.

You changed this check so it's no longer case-sensitive. Why? If there's a typo in the prefix, I think we would want to cause an error, not allow it to go through silently... possibly returning a type that was not intended.

Also, the old code is much more future-proof, and we don't need to maintain a case statement each time the enum set changes. I don't think the fixed-size stream over the enum values array is performance-critical, and should be fine.

I restored the case sensitivity in 5a5905f. I also modified the method to loop over the enum values so that it should be more future-proof.

I don't think the fixed-size stream over the enum values array is performance-critical, and should be fine.

If I had my way, I would change all the occurrences of streams in the entire code base back to for-loops. While the streams api may be more intuitive for some, everyone knows what a for loop is. We are choosing to use an api that we know is slower. If we were developing a calendar app, I would agree that performance is not critical. For a database, I think performance is critical and should be a design goal. On a lightly loaded system the implementation of a non-critical section of code doesn't matter. On a highly loaded system, the implementation of a non-critical section of code is preventing other code from running.

I don't mind changing this instance to a for loop, but I do find the 12 new lines much more verbose and much less readable than the succinct 2 lines that were there before, and don't see this as an overall improvement. I think it would probably be more clearly an improvement if it didn't have the redundant checks for the special cases being checked before the loop, since those are already encapsulated by the check at the end of the loop. Those cases should be rare, so there's not an optimization to bypass the loop for them. The verbosity of the checks undermines any value the more specific error messages might have offered. I think the succinct check at the end is sufficient.