TomThomson (3/27/2015)
Jeff Moden (3/26/2015)
My recommendation would be to do those kinds of checks externally rather than adding them to the function. Changes for convenience will slow things down when it's not convenient. It's built to do just one thing as fast as possible.I have to agree. There's no logical reason to choose a behaviour other than the current one (as I said before, looking at the requirements and the "science" and the deficiencies of SQL leaves effectively a free choice of behaviour for the NULL parameter case) and there's a very good performance reason not to change that behaviour.
From my personal point of view, it's a bonus that the current behaviour seems more logical to me wearing my scientst hat than the alternatives do. So my engineer instinct and my science instinct agree (and I hate it when they don't :-)).
I agree 100%. A NULL value still exists in a row. Not only does the function make sense to me with its current behavior, but the performance impact of implementing that parameter simply isn't worth the flexibility it provides. You can always put a WHERE clause on your calling query when you need it.