DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=TCMFSIwzjMBCzkwUshTeoe4VhpF7jh7dGm5xk5XKGOnAepiA+mJw71UUtxUswY1X4U3O2VfGEVkKpHtW4yAnNyVxVNST5MjXY7HTKTOCnKjzpHjyxWaqhN3RND6uF6H9kDp6VWDn0Wu+OUU6+TdCGmDK5SVhvEFBjDqMbjTJNTY=
Message-ID: <b42b73150805140809q609ff25t3ca51cf633fc24e9@mail.gmail.com>
Date: Wed, 14 May 2008 11:09:25 -0400
From: "Merlin Moncure" <mmoncure@gmail.com>
To: "Bruce Momjian" <bruce@momjian.us>
Subject: Re: libpq object hooks
Cc: "Andrew Dunstan" <andrew@dunslane.net>,
	"Alvaro Herrera" <alvherre@commandprompt.com>,
	"Patches (PostgreSQL)" <pgsql-patches@postgresql.org>,
	"Andrew Chernow" <ac@esilo.com>
In-Reply-To: <200805141452.m4EEqh814039@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <b42b73150805140723y71d0a6e2mc325e64d1a0df9f7@mail.gmail.com>
	<200805141452.m4EEqh814039@momjian.us>

On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <bruce@momjian.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