Hi Toni
Hmmm... sounds like you want to do something similiar to SqlBackend's SqlConvertedBooleanExpression. Since a Boolean is represented differently in SQL depending on where it is used (i.e. in a select clause or inside a condition, etc), we have to wrap boolean expressions and use a ConvertExpression in some places.
The magic for this happens via the ISqlConvertedBooleanExpressionVisitor and SqlConvertedBooleanExpression. You can extend the visitors (the SqlGeneratingOuterSelectExpressionVisitor and possiblity SqlGeneratingExpressionVisitor) by deriving and updating the callsite (DefaultSqlGenerationStage) to handle the new expression type. And you'll need to decide if the special syntax is only warrented on the outer-most projection or also deeper in the tree.
There is also a completely different option: Transformations:
https://www.re-motion.org/blogs/mix/2011/04/29/re-linq-customizability-explained/You can register transformations for different expression types and since you've already provided your own expression type, that could be a way to do this. You'd get the source expression and return an expression tree that generates all the stuff you need via SqlFunctionExpression, SqlLiteralExpression, etc.
Sidenote about a specific extension point to add sql features not natively supported in the backend: Projects have added extensions for date-time operations for instance via this mechanism (AttributeEvaluatingExpressionTransformer
) There's also a sample in the unit tests for the SqlBackend: FullNameEqualsTransformerAttribute. This is of course only feasible, when you can add a specfic method call every time you need the feature in the query.
Can't really say which one's better, depends on the details. Generally, the transformations are for when you just need to turn something simple into a more complex structure with existing syntactic elements.
Best regards, Michael