I am more interested in the motivation where it is stated:
Many users have the need of masking sensitive data, such as contact info,
> age, gender, credit card numbers, etc. Dynamic data masking (DDM) allows to
> obscure sensitive information while still allowing access to the masked
> columns, an
Maybe a small improvement is the redacted value could be of the form
`XXX1...1000` meaning XXX followed by a rand number from 1 to 1000:
XXX54, XXX998, XXX456,... Some randomness would prevent some apps
flattening all rows to a single XXX'ed one, giving a more realistic
redacted data distributi
>
> > If the column names are the same for masked and unmasked data, it would
> impact existing applications. I am curious what the transition plan look
> like for applications that expect unmasked data?
For example, let’s say you store SSNs and Birth dates. Upon enabling this
> feature, let’s say
> On 21 Aug 2022, at 14:59, Benedict wrote:
>
> SELECT INTO in T-SQL creates a new table with the results. Since our
> semantics are likely to be different than Postgres and MySQL, I’m not sure
> it’s less confusing or otherwise beneficial to mimic an existing syntax.
>
> Personally I find
Proposing the test build of Cassandra 4.0.6 for release.
sha1: eb2375718483f4c360810127ae457f2a26ccce67
Git:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.6-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-/org/apache
