XPost: microsoft.public.sqlserver.programming
From: hugo@perFact.REMOVETHIS.info.INVALID
On Wed, 05 Jan 2011 16:04:57 -0800, Gene Wirchenko
wrote:
> Why not?
Hmm, I guess I didn't explain well enough.
The point I was trying to make in the previous example, is that in
SOME cases, a deterministic function can become non-determinstic as a
result of changed to another object. When the function f2 is made, it
uses a view that is precise and deterministic. At that point, the SQL
engine *could* decide to mark the function as deterministic and
precise as well. But after the ALTER VIEW, this is no longer true.
The development team had basically four choices:
1. Base IsDeterministic and IsPrecise on the situation when the
function is created and ignore later changes, so that a function that
is no longer precise can still be marked as precise - I don't know
about you, but I would report a bug if I encountered this behaviour.
2. After an ALTER VIEW, check each and every object that is directly
or indirectly dependant on the view and correct the IsDeterministic
and IsPrecise attrbiutes. Probably a large engineering investment.
3. Analyse the function, require it to be schema-bound if the
IsDeterministic and IsPrecise attributees depend on some other object
but don't require schemabound if it is independent.
4. Alsways require the function to be independent.
My speculation is that the team discarded options 1 and 2, then
weighed the engineering effort for option 3 versus the user impact of
option 4 and decided that option 3 was not the optimal way to spend
their engineering dollars.
If you disagree, you can of course always suggest a change in this
behaviour: http://connect.microsoft.com/SQLServer
--
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
