On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote: > Our manual says we can use pgcrypto functions or encrypted filesystems > for data encryption. > http://www.postgresql.org/docs/8.4/static/encryption-options.html > > However, they are not always the best approaches in some cases. > > For pgcrypto functions, user's SQL must contain keyword strings > and they need to consider which column is encrypted. Users complaint > that that they want to treat encrypted values as if not-encrypted.
As others have said, handling encryption client side would seem to offer many more benefits (transparently within libpq offering easy adoption). > passward() and options() are SQL functions and we can re-define them > if needed. The default implementations are to refer custom GUC variables > (pgcrypto.password and pgcrypto.options) so that encryption are done > only in database server and applications don't have to know the details. Should the password be this widely shared? it would seem to make more sense if it was a write-only variable and never exposed outside the crypto module. You wouldn't even need to be a super-user to collect all the passwords otherwise, just create a function that has the name of something common and have it stash the password aware somewhere. -- Sam http://samason.me.uk/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
