From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Damian Wolgast <damian(dot)wolgast(at)si-co(dot)net>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Column Redaction |
Date: | 2014-10-10 10:35:09 |
Message-ID: | 20141010103509.GZ28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon,
* Simon Riggs (simon(at)2ndquadrant(dot)com) wrote:
> The requirement for redaction cannot be provided by a view.
>
> A view provides a single value for each column, no matter whether it
> is used in SELECT or WHERE clause.
>
> Redaction requires output formatting only, but unchanged for other purposes.
>
> Redaction is now a feature available in other databases. I guess its
> possible its all smoke and mirrors, but thats why we discuss stuff
> before we build it.
In general, I'm on-board with the idea and similar requests have come
from users I've talked with.
Is there any additional information available on how these other
databases deal with the questions and concerns which have been raised?
Regarding functions, 'leakproof' functions should be alright to allow,
though Heikki brings up a good point regarding binary search being
possible in a plpgsql function (or even directly by a client). Of
course, that approach also requires that you have a specific item in
mind. Methods to mitigate would include not allowing regular users to
create functions or run DO blocks and rate-limiting their queries, along
with appropriate auditing.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2014-10-10 10:42:43 | Re: Column Redaction |
Previous Message | Heikki Linnakangas | 2014-10-10 10:27:26 | Re: Column Redaction |