On Tue, Apr 15, 2008 at 10:48 AM, <tomas@tuxteam.de> wrote:
> On Tue, Apr 15, 2008 at 09:48:37AM -0400, Merlin Moncure wrote:
> > On Tue, Apr 15, 2008 at 9:36 AM, Alvaro Herrera
> > <alvherre@commandprompt.com> wrote:
>
> > > I expect you intend to get at least the hooks in, right?
> >
> > not likely. Keep in mind, this is not how we really wanted to do
> > things in the first place. We don't think this is the right strategy
> > for integrating libpqtypes with libpq. It over-complicates things and
> > we don't really see a use case outside of libpqtypes. If a reasonable
> > case can be made for putting the hooks in, we will consider it. Can
> > you think of any good reasons for hooking libpq outside of our
> > intentions?
>
> Yes, this one comes to mind:
>
> From: sanjay sharma
> Subject: Submission of Feature Request : RFC- for Implementing
> Transparent Data Encryption in Postgres
> <http://archives.postgresql.org/pgsql-hackers/2008-03/msg01231.php>
>
> I know that the original poster wanted to encrypt and decrypt things
> server-side, but as was noted in the thread this doesn't make that much
> sense because the decryption keys must be somehow kept around there.
>
> But for doing it transparently client-side such libpq hooks might come
> in handy...
libpqtypes was designed to handle this with our without hooking. (the
'hooking' debate was mainly about exactly how libpq and libpqtypes was
going to be separated).
libpqtypes had a superclassing concept (not much discussed on the
lists) where you could introduce new type handlers that wrapped
existing ones and was desgined exactly for things like this. keep an
eye on our upcoming pgfoundry project.
merlin