From: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com> |
Cc: | "Andrew Chernow" <ac(at)esilo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pulling libpqtypes from queue |
Date: | 2008-04-15 13:48:37 |
Message-ID: | b42b73150804150648g227fc742mb7e1823a0015d28c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 15, 2008 at 9:36 AM, Alvaro Herrera
<alvherre(at)commandprompt(dot)com> wrote:
> Andrew Chernow escribió:
> > 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.
>
> I expect you intend to get at least the hooks in, right?
not likely. Keep in mind, this is not how we really wanted to do
things in the first place. We don't think this is the right strategy
for integrating libpqtypes with libpq. It over-complicates things and
we don't really see a use case outside of libpqtypes. If a reasonable
case can be made for putting the hooks in, we will consider it. Can
you think of any good reasons for hooking libpq outside of our
intentions?
PQmakeResult, PQsetValue, and PQresultAlloc OTOH, we think are good
functions and stand up on their own merits. At minimum we will fully
support their inclusion into 8.4. (we are readying a patch for that).
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2008-04-15 13:51:33 | Re: pulling libpqtypes from queue |
Previous Message | Ana Carolina Brito de Almeida | 2008-04-15 13:48:00 | stack smashing detected |