This patch has been lingering around since Aug 2007. It has matured a
lot and now calls libpq home. Unfortunately, ISTM that there is limited
support for our proposal. We either pitched to the wrong crowd or
pqtypes doesn't have the mass appeal we expected. With that said, we
are considering shopping this elsewhere ... ie. pgfoundry.
At this point, we feel this has gone in the wrong direction. Our goal
was to add some pqtype api calls to libpq (directly or as stubs). We
now find ourselves implementing a hook API which is opposite of our
proposal. We did try to make it work, but there are many dirty details
that make it unworkable and beneath the quality of the rest of the
postgresql project.
Even though the library size issue was solved, by using stub funcs and
dlopen, it appears there are other reasons for rejecting pqtypes. BTW,
all we have heard in regards to stub funcs are crickets.
pqtypes is bowing out for now :( If the community wants to run with it,
we will help in any way we can. We will continue to manage this
ourselves; most likely as stub funcs. Keep in mind, we were using
pqtypes (in a raw form) for 8 months before submitting it to the
community. We thought it would be useful to others and we wanted to
give back.
We appreciate everyone's willingness to get this working. We respect
the fact that with little interest (or good old distaste), everyone was
still willing to add api calls to make this work. We appreciate this
and think it demonstrates one of the community's strengths.
Thanks again for your time and suggestions.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
