Why not cascade? (was: Using varchar primary keys)

On 3/4/13 at 1:49 PM, dix1wjifgt@sneakemail.com (Julian 
tempura-at-internode.on.net |pg-gts/Basic|) wrote:

>... having to really think it out is probably a good sign that you
>should stick to a surrogate unless you are really sure. (again I don't
>advocate ON UPDATE CASCADE as a solution should you change your mind)
>
OK this is interesting.

Why not cascade?

Assuming someone makes the dB design as straight forward as 
possible, avoids obfuscation of key values (since this mostly 
only gets the present and the next developer into trouble, not 
the mythical external hacker), and has constraints with cascaded 
updates in place to keep it all consistent. Something changes in 
the real world, the DBA makes the dB reflect this change and the 
cascade ensures everything is still consistent. Where is the 
problem with this?

When there is a lot of work involved this needs to be taken into 
account, but what is the basis for such a general prohibition on 
a modern SQL dB? why not use the feature?

Regards
Gavan Schneider