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

Re: libpq object hooks

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Bruce Momjian" <bruce(at)momjian(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, "Andrew Chernow" <ac(at)esilo(dot)com>
Subject: Re: libpq object hooks
Date: 2008-05-14 15:09:25
Message-ID: b42b73150805140809q609ff25t3ca51cf633fc24e9@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Merlin Moncure wrote:
>> Regarding the other comments:
>> *) API structure: Our major objective was to minimize exports to
>> libpq.  I think both copyresult and setvalue have some possible
>> sideband usage (footguns or no).  Additional functions could be
>> speculated but are not required by libpqtypes.  We would have no
>> problem adding a few things to complete the api if necessary.
>>
>> The patch is basically the minimum libpqtypes needs and has to work
>> more or less as written.  We tried a few times to suggest implementing
>> the split a different way (basically, more invasion into libpq).  We
>> couldn't get any action there.
>>
>> If the patch is rejected on general merits...that signals the death
>> blow for libpqtypes.  We have a chicken/egg problem...people can't use
>> it without patching libpq which will really hamper its adoption, which
>> is, uh, needed to justify the patch.  For the record, we have had a
>> couple of dozen downloads of the libpqtypes library on pgfoundry since
>> we put it up there last week.  Based on how it has simplified and
>> improved our own code vs. libpq, we have absolutely no doubts it is a
>> major improvement over PQexecParams.
>
> One idea would be to add the libpq hooks but not document them.  This
> way, we can modify or remove the API as needed in the future.  As
> libpqtypes matures and we are sure what the API should be, we can
> document it as stable and permanent.

The API functions relating to hooks are unlikely to change once
settled on...but PQsetvalue/PQcopyResult are a good fit with your idea
(they introduce new behaviors that could possibly be used outside of
libpqtypes context, and could require changes down the line).

merlin

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2008-05-14 15:16:42
Subject: CVS HEAD warnings fixed
Previous:From: Merlin MoncureDate: 2008-05-14 15:06:02
Subject: Re: libpq object hooks

pgsql-patches by date

Next:From: Andrew ChernowDate: 2008-05-14 16:02:17
Subject: Re: libpq object hooks
Previous:From: Merlin MoncureDate: 2008-05-14 15:06:02
Subject: Re: libpq object hooks

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