The discriminator column could be literal. But the VALUE needs to be dynamic. Classic example is same app accessed via two different URLs: tenant1.somesite.com and tenant2.somesite.com The discriminator values - tenant1 and tenant2 in this case - are not known a priori and must be dynamically resolvable when the SQL is emitted. (Not sure if that was the design question, if I got it wrong, please clarify.)

I think it's OK if in V1 we can't filter native SQL queries - so long as we had a consistent way to parameterize those too so that the author/developer could change those queries to support multi-tenancy in a way that's consistent with the parts we can automate.