Thread: libpq++
Who are maintainer of libpq++? --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net
On Mon, 29 Mar 1999, Dmitry Samersoff wrote:
>
> Who are maintainer of libpq++?
I was going to when things settled down, but a couple of months ago
someone else posted to hackers that they had an immediate need and was
going to so I backed off.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
>> Who are maintainer of libpq++?
> I was going to when things settled down, but a couple of months ago
> someone else posted to hackers that they had an immediate need and was
> going to so I backed off.
I haven't noticed any patches getting posted, however, so whoever-it-was
seems to have lost interest. Vince, if you still are interested in
adopting libpq++, it desperately needs a caring parent ;-)
regards, tom lane
On Mon, 29 Mar 1999, Tom Lane wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
> >> Who are maintainer of libpq++?
>
> > I was going to when things settled down, but a couple of months ago
> > someone else posted to hackers that they had an immediate need and was
> > going to so I backed off.
>
> I haven't noticed any patches getting posted, however, so whoever-it-was
> seems to have lost interest. Vince, if you still are interested in
> adopting libpq++, it desperately needs a caring parent ;-)
Lemme see what it'll take to get up to speed. Yesterday while I was
BBQ'in I got the last three items finished up that were sitting on the
top of the pile for the last four months (they weren't small) so I've
actually got some time. I'll let ya know.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
On 29-Mar-99 Tom Lane wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
>>> Who are maintainer of libpq++?
>
>> I was going to when things settled down, but a couple of months ago
>> someone else posted to hackers that they had an immediate need and was
>> going to so I backed off.
>
> I haven't noticed any patches getting posted, however, so whoever-it-was
> seems to have lost interest. Vince, if you still are interested in
> adopting libpq++, it desperately needs a caring parent ;-)
Looking at it now. I see the first thing I'm going to have to do is
fix the docs - second actually, I need to find out why it didn't build
in my tree in the first place back when I went thru the docs in December.
Are there any glaring problems that require immediate attention that you
know of? I see it hasn't been touched since around '97.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
On 29-Mar-99 Vince Vielhaber wrote: > > On 29-Mar-99 Tom Lane wrote: >> Vince Vielhaber <vev@michvhf.com> writes: >>>> Who are maintainer of libpq++? >> > > Are there any glaring problems that require immediate attention that you > know of? I see it hasn't been touched since around '97. Probably, official libpq need to go to templates and exceptions, stop supporting unusable g++ 2.7.2 ( I use self-written completely different version of C++ interface. It use exceptions for error reporting and some convenientoverloads like ["field name"]. ) --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net
Vince Vielhaber <vev@michvhf.com> writes:
> Are there any glaring problems that require immediate attention that you
> know of? I see it hasn't been touched since around '97.
The connection-related routines desperately require work; the only
interface is equivalent to PQsetdb(), which means there's no way to
specify username/password. (Except by passing them via environment
variables, which is a kluge.) The code should be calling PQsetdbLogin
and there need to be a couple more connection parameters for username/
password.
I'd also like to see a connection method that interfaces to
PQconnectdb() and passes everything in a string, forgetting the
pgEnv stuff entirely. That's the only way that won't require
further attention if more connection parameters are added to libpq.
Also, if the routines immediately around the connection code are
any indication, the library is just crawling with bugs. A few
examples:
1. PgConnection::Connect tests "if (errorMessage)" ... where
errorMessage is a locally declared char array. In other words
the if() tests to see whether the address of errorMessage is non-null.
This means that PgConnection::Connect *always* thinks it has failed.
The symptom that has been complained of is that if PQsetdb actually
does fail, no useful error message is available, because
PgConnection::Connect has overwritten it with the usually-null
message from fe_setauthsvc().
2. If it were coded as probably intended, ie "if (errorMessage[0])",
then it would not be testing the *connection* status but only whether
fe_setauthsvc was happy or not. The test should really be looking at
the returned pgConn.
3. If it's gonna call fe_setauthsvc, one would think it should not go
ahead trying to make the connection if fe_setauthsvc fails. But it does.
4. It probably shouldn't be calling fe_setauthsvc in the first place,
that routine being obsolete and deprecated.
5. Why are the caller(s) of PgConnection::Connect not noticing its
failure return status?
I got sufficiently discouraged after deconstructing that one routine
that I didn't go looking for more problems. Five bugs in ten lines
of code is not promising...
regards, tom lane
On 01-Apr-99 Tom Lane wrote:
> Vince Vielhaber <vev@michvhf.com> writes:
>> Are there any glaring problems that require immediate attention that you
>> know of? I see it hasn't been touched since around '97.
>
> The connection-related routines desperately require work; the only
> interface is equivalent to PQsetdb(), which means there's no way to
> specify username/password. (Except by passing them via environment
> variables, which is a kluge.) The code should be calling PQsetdbLogin
> and there need to be a couple more connection parameters for username/
> password.
Last nite I started looking at it a bit closer (docs are fixed and
sent to Tom). Without trying to use any of it I was asking many of
the same questions that you're mentioning here.
> I'd also like to see a connection method that interfaces to
> PQconnectdb() and passes everything in a string, forgetting the
> pgEnv stuff entirely. That's the only way that won't require
> further attention if more connection parameters are added to libpq.
Prior to eliminating anything (like the pgEnv stuff), do we know how
many people are using libpq++? I'm wondering which would be better,
clean break or a phase out.
Remaining items noted - as well as the items that Dmitry mentioned the
other day.
I can see some directions I can go in with this. The library looks like
it has a home/"caring parent" now. :) I'll be a bit slow starting,
especially with the holiday coming up and a convention following that, so
making it before 6.5 release is doubtful (hopeful, but doubtful, but
probably not wise anyway).
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> On 01-Apr-99 Tom Lane wrote:
>> I'd also like to see a connection method that interfaces to
>> PQconnectdb() and passes everything in a string, forgetting the
>> pgEnv stuff entirely. That's the only way that won't require
>> further attention if more connection parameters are added to libpq.
> Prior to eliminating anything (like the pgEnv stuff), do we know how
> many people are using libpq++? I'm wondering which would be better,
> clean break or a phase out.
I'd say phase out: there's no reason not to support both styles for a
while (just as libpq is still supporting PQsetdb). But in the long run
I'd like to encourage apps to move towards using the PQconnectdb
interface. The idea is to avoid exactly the problem we see in libpq++:
interface layers that know about a specific set of connection parameters
and have to be fixed anytime more are added.
To answer your question, there are at least some people using libpq++,
since we get bug reports and inquiries about it. Hard to say how many.
regards, tom lane