Thom Brown <t...@linux.com> wrote: > On 10 October 2014 15:56, Stephen Frost <sfr...@snowman.net> wrote: >> Thom Brown (t...@linux.com) wrote: >>> Data such as plain credit card numbers stored in a >>> column, even with all its data masked, would be easy to determine. >> >> I'm not as convinced of that as you are.. Though I'll point out that in >> the use-cases which I've been talking to users about, it isn't credit >> cards under discussion. > > I think credit card numbers are a good example.
I'm not so sure. Aren't credit card numbers generally required by law to be stored in an encrypted form? > If we're talking > about format functions here, there has to be something in addition to > that which determines permitted comparison operations. If not, and we > were going to remove all but = operations, we'd effectively cripple > the functionality of anything that's been formatted that wasn't > intended as a security measure. It almost sounds like an extension to > domains rather than column-level functionality. I have to say that my first thought was that format functions associated with types with domain override would be a very nice capability. But I don't see where that has much to do with security. I have seen many places where redaction is necessary (and in fact done), but I don't see how that could be addressed by what Simon is proposing. Perhaps I'm missing something; if so, a more concrete exposition of a use case might allow things to "click". -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers