Re: [GENERAL] Libpq++ autenthication problem II - Mailing list pgsql-general

I'm posting this also to the mailing list since I think it could be of
public interest...

Bruce Tong wrote:
>
> > I'm having some problems trying to use the "password" and "crypt"
> > authentication protocols in my libpq++ apps.
>
> I've had trouble finding information about LIBPQ++ too, as have a number
> of others. Before I knew LIBPQ++ existed, I started writing my own classes
> to surrounded the LIBPQ library. I'm not finished, but I'd be happy to
> share the code with you if you think it would be helpful.
>
> Bruce Tong
> Systems Programmer
> Electronic Vision / FITNE
>
> mailto: zztong@laxmi.ev.net
> http://www.ev.net/fitne

Tanx. In my intentions I would simply rewrite some pieces of libpq++ in
order to make it more "modern". In my opinion in fact libpq++ is not
mantained by anyone of the main developers.

I do hope to be wrong but I'm comparing the sources and see no updates
in the last versions.

They are mantaining libpq since it is the source they use to make their
psql shell work with. Libpq++ on the other side is seen as a "plus" that
a serious package "must" have to be considered full featured, even if it
really does not work at 100%.
It was true also for ODBC drivers, until Byron of Insight (thanks
again!) rewrote them from scratch and made them commercial quality (and
PostgreSQL must AT LEAST and at a whole be commercial quality to compete
with other products).

I'll appreciate your sources, expecially the .h files, since there will
be surely some good idea I forgot of putting in my sources.



Anyhow, since you are interested in libpq would you comment about my
ideas:

- The concepts we see in libpq++ are not bad. So I won't rewrite the
bulk of it.

- Remove the actual connection code from all constructors. I hate the
concept that every new feature you add in a base class to provide new
means of connections (say to PgConnection) you have to propagate it to
all derived classes (since constructors are not inheritable). It's
against easy reusability. Moreover I see some constructors to be useless
if not conflictual to an upgraded management.

Take for example PgConnection(const char* dbName). In the docs it states
it performs a connection to database dbName with "reasonable" defaults.

First, in C++ we can specify defaults that we could use to write
something like:

PgConnection(const char* dbName, const char* host = 0 and so on...)

in order to see by our eyes what are the reasonable defaults (and docs
to search for infos about PostgreSQL stuff are never enough abundant or
easy to understand for us "poor C++ suckers" or for novices).

Moreover, given PgConnection(const char* dbName) I cannot override it
with such an useful statement like:

PgConnection(const char* ConnectionString)

where ConnectionString is similar to the new connection string we can
use with libpq's PQconnectdb() and appears like:

"user=username password=userpwd dbname=mydbname host=myhost port=5432"

- I'd rather follow the good, old Borland style of giving minimal
constructors and to put the big stuff in another conventional function,
like Init(). If we make this function virtual, we can avoid recalling it
"recursively" as it is now using constructors.



Any idea and discussion will be much appreciated!


Best regards,

Dario Fumagalli

Art & Media
Via Villa Giusti, 11 - 10142 Torino (Italy)
Tel. +39-11-7707412 PBX - Fax +39-11-704283
email swdevel@art-media.it
      dfumagalli@art-media.it (personal mail slot)
http://www.art-media.it