| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Erik Aronesty <erik(at)q32(dot)com> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: pgcrypto question |
| Date: | 2019-10-07 19:49:51 |
| Message-ID: | 20191007194951.jxdmeiqobifx4ja4@development |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Oct 07, 2019 at 02:51:30PM -0400, Erik Aronesty wrote:
>Good idea for "psycopg". It would be easy for a POC, but I think the
>only meaningful layer to operate at would be a libpq drop-in
>replacement that intercepts PQgetvalue, PQprepare, PQexecParams,
>PQexecPrepared ... etc. That way odbc, python, node, etc would "just
>work".... as long as you used LD_PRELOAD appropriately.
>
It's not clear to me how would that know which columns are encrypted,
with what key, etc. Because those encrypted columns are essentially just
regular bytea columns, so there's no easy way to distinguish them.
I'm no psycopg2 expert, but it does have some infrastructure for casting
PostgreSQL types to Python types, and I guess that could be used for the
encryption.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2019-10-07 20:12:52 | Re: Event Triggers and Dropping Objects |
| Previous Message | Erik Aronesty | 2019-10-07 18:51:30 | Re: pgcrypto question |