Thread: Re: [GENERAL] Libpq++ autenthication problem II

Re: [GENERAL] Libpq++ autenthication problem II

From
Dario Fumagalli
Date:
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

Re: [GENERAL] Libpq++ autenthication problem II

From
Bruce Tong
Date:
> > 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.

http://vishnu.ev.net/~zztong/postgres/libpq

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

My efforts were mostly to design something which would not be as prone to
memory leaks as I thought the LIBPQ libraries might be for a developer who
doesn't spend a lot of time working with the library.

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

The organization of the classes confused me. I remember thinking it
strange certain classes inherited from others. Its been a few weeks since
I looked at LIBPQ++. I was content to build around LIBPQ since it was
mostly documented. I'm weak on database theory, so the LIBPQ++ design
might make sense, and my C++ classes might be rather shallow. As I
mentioned before, my attempts were mostly to bullet-proof LIBPQ.


Bruce Tong
Systems Programmer
Electronic Vision / FITNE

mailto: zztong@laxmi.ev.net
http://www.ev.net/fitne


Re: [GENERAL] Libpq++ autenthication problem II

From
Bruce Momjian
Date:
> The organization of the classes confused me. I remember thinking it
> strange certain classes inherited from others. Its been a few weeks since
> I looked at LIBPQ++. I was content to build around LIBPQ since it was
> mostly documented. I'm weak on database theory, so the LIBPQ++ design
> might make sense, and my C++ classes might be rather shallow. As I
> mentioned before, my attempts were mostly to bullet-proof LIBPQ.
>

I have always felt the libpq++ really did not take full advantage of
C++, but did not have the time to really think about how it should be
improved.  Good luck.

--
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)