Ivan,
I've been talking with different users from different industries and some
of them(definitely not all of them) consider schema sensitive information.
As a framework, that can be used by different types of users, we should
cover this use case too. The solution, suggested by Ilya sounds very
Ilya, great idea, but I suppose that third option is a little bit paranoid.
But nevertheless, let it be, it's quite simple to implement it.
пн, 5 апр. 2021 г. в 14:04, Ilya Kasnacheev :
> Hello!
>
> I have two ideas here:
>
> - Let's have more than a single level of sensitive information
Taras, it's strange that table schema and binary object schema are
considered sensitive information. I suppose, that current realization is
what it is because of simplicity of implementation.
I've never heard from any cybersecurity expert, that sql plan or table
schema are personal or sensitive
Hello!
I have two ideas here:
- Let's have more than a single level of sensitive information withholding.
Currently it is on/off, but I think we may need three levels: "print all",
"print structure but not content", "print none".
By structure I mean table/column/field names and data types. So we
Hi,
I work on ticket IGNITE-14441 [1] to hide sensitive information at the
log messages produced by SQL.
There are negative comments for the patch.
I guess we have to produce view to work with sensitive information and
make rules to define sensitive information.
See on the usage of the
