>Examples of the problem: EnumerableWindowRule, > EnumerableFilterRule
That looks like a bug, and we should probably fix it (ensure #create methods are used that compute traits as needed) However, it looks like the common pattern is to compute traits from metadata query, so the question might be "why do we hard-code a couple of collation+distribution traits? What if we re-compute all the traits?". >But given that the distribution is not supported by Enumerable In practice, EnumerableFilter won't affect distribution, so it could be OK to keep distribution trait for EnumerableFilter. On the other hand, Project might indeed affect distribution, so EnumerableProject could keep distribution trait just fine. I'm not sure "enumerable does not support distribution" is the right way to put things. distribution is an in-core trait, so I believe EnumerableProject and EnumerableFitler should support it properly. However, it might indeed be sane to reset all the unknown traits to the unknown state for "input enforcement". I am not sure if we could/should make input enforcement customizable with something like metadataquery though. Vladimir
