Skip site navigation (1) Skip section navigation (2)

Re: libpq object hooks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Chernow <ac(at)esilo(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: libpq object hooks
Date: 2008-05-15 18:19:16
Message-ID: 9458.1210875556@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Andrew Chernow <ac(at)esilo(dot)com> writes:
> There can be cases to use the same callbacks, although unlikely.  To 
> completely avoid collisions, the below would work:

Still looks like overdesign to me.  If we use the hook function address
we solve the problem with no extra notation and no extra storage.

Note that if you want N fixed keys, you can just have N hook functions
(all calling a shared workhorse routine, no doubt).  So your proposal
adds no functionality whatever if the usage involves a fixed number of
static handles.  Now it could possibly allow a variable-at-runtime
number of handles, but I'd want to see a worked-out use case before
designing for that much complexity.  In particular, it seems to me that
the problem would then shift to how do you know which handle to use for
the lookup, thus you've just introduced another layer of complexity
without buying anything.

I think the typical use case is just that you need to distinguish "your"
hook from anyone else's hooks, so the function address is plenty
sufficient.

It should also be noted that this whole problem *can* be solved without
any PQhookData at all: as long as you have hooks to get control at
creation and destruction of PGconns and PGresults, you can maintain your
own index data structure.  I'm willing to grant some amount of extra
API-stuff to save users having to do that in simple cases, but I don't
think we need to try to support infinitely complex cases.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Andrew ChernowDate: 2008-05-15 18:36:42
Subject: Re: libpq object hooks
Previous:From: Magnus HaganderDate: 2008-05-15 18:10:33
Subject: Re: SSL and USER_CERT_FILE

pgsql-patches by date

Next:From: pgsqlDate: 2008-05-15 18:24:51
Subject: SSL client configuration patch
Previous:From: Tom LaneDate: 2008-05-15 18:08:03
Subject: Re: libpq object hooks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group