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/
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 |