Allow Hashdiff to be case sensitive seperately from hash keys

[barrystr]

Is your feature request related to a problem? Please describe.
We have a requirement to make hashdiff results case sensitive while keeping the hash keys as case insensitive

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
I have added a new variable hashdiff_content_casing that can be set to upper or disabled in the same way as the hash_content_casing. Changes were required to standard_column_wrapper to accept the is-hashdiff parameter. hash amd null_expression were changed to pass the parameter.

Additional context
We considered making both the keys and hashdiff case sensitive but we did still need the keys to remain as they were.

AB#5614

[barrystr]

I've applied the changes I made to this codespace - https://expert-space-meme-9g9wxvrwwgp2x9g4.github.dev/

[DVAlexHiggs]

Hi! Thanks for this 😄 This has been requested for a while but hasn't been implemented yet due to other priorities - we'll make sure this goes into an upcoming release

[chrispuuri]

@DVAlexHiggs would this allow for hash keys or hash_diff columns to be varchar instead of binary? I different need but can envision how it would be solved by this same feature considering the ability to allow hash_diff columns would mean they are varchar instead of binary. It would be nice to have this as a project level variable.

[DVAlexHiggs]

@DVAlexHiggs would this allow for hash keys or hash_diff columns to be varchar instead of binary? I different need but can envision how it would be solved by this same feature considering the ability to allow hash_diff columns would mean they are varchar instead of binary. It would be nice to have this as a project level variable.

If you're talking about allowing natural keys instead of needing to hash then that's a slightly different (but definitely adjacent) feature.

The data vault standard already supports this, and the only reason we haven't explicitly said anywhere that AutomateDV does as well is because we haven't tested it fully yet and we're being cautious.

However, if the code didn't assume a binary type for the src_pk then I believe it would work without any other code changes. It's important to understand though that - depending on your platform - it could cause a performance hit (e.g. Snowflake is better at handling unhashed keys, especially in a data vault context)