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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
