Re: pulling libpqtypes from queue

From: Andrew Chernow <ac(at)esilo(dot)com>
To: tomas(at)tuxteam(dot)de
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pulling libpqtypes from queue
Date: 2008-04-16 11:07:38
Message-ID: 4805DDFA.5070906@esilo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

tomas(at)tuxteam(dot)de wrote:
>>>
>>> > > I expect you intend to get at least the hooks in, right?
>
> [...]
>
>> 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.
>
> That sounds cool. So in a way you do have the hooks.
>

A patch has been submited for supporting libpq object hooks, which allows one to
associate private storage with a PGconn or PGresult object. The hook is called
when a conn or result is created or destroyed (PQreset for conn as well).

http://archives.postgresql.org/pgsql-patches/2008-04/msg00309.php

For libpqtypes, this means it can operate outside of libpq. libpqtypes was
initially designed as a direct extension to libpq (internal code), but the
community prefered using a generic hook interface that allowed libpqtypes to
work externally.

--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2008-04-16 11:12:47 Re: pg_terminate_backend() issues
Previous Message Gregory Stark 2008-04-16 10:43:00 Re: pg_terminate_backend() issues