On Wed, May 14, 2008 at 10:52 AM, Bruce Momjian <[EMAIL PROTECTED]> 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 -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
