There seems to have been an accumulation lately of stuff that was simply
dumped into the source tree without any sort of integration.  I am
particularly talking about interfaces/ssl and interfaces/libpqxx.  No
doubt both of these things are useful in the end, but as they are right
now they're a headache waiting to happen.

Could someone try to address the following issues?

SSL:

* A bunch of cryptic configuration files -- what do they do?

* Weird shell scripts -- what do they do?

* The shell scripts are written in a completely unportable fashion and
have inappropriate names (surely PostgreSQL isn't the only application in
the world that allows to "mkcert").

* They don't even belong into interfaces.

* No build instructions, let alone a makefile.

Libpqxx:

* I'm no C++ whizz, but I guarantee that this coding style is not nearly
as portable as we've tried to make libpq++ be.  Who wants to answer those
support calls all over again?

* What's the deal with libpq++ vs. libpqxx?  Who's going to want to
explain that to the crowd for the next 5 years?

* Bogus Automake stuff -- hurts my eyes. ;-)

* Doxygen -- is that going to be a quasi-required tool now?

* Bonus points for documentation in DocBook format -- but unfortunately
version 4.1, and unfortunately not integrated with the rest of the
documentation set.

* No build integration.

* Why are half the text files executable?

Personally, I'm uneasy about carrying around another interface library
that appears to have no basis in any sort of standard.

-- 
Peter Eisentraut   peter_e@gmx.net



Wed, 10 Jul 2002 00:18:16 +0200 (CEST)
Peter Eisentraut <peter_e@gmx.net>
Unintegrated stuff in source tree
Peter Eisentraut wrote:
> There seems to have been an accumulation lately of stuff that was simply
> dumped into the source tree without any sort of integration.  I am
> particularly talking about interfaces/ssl and interfaces/libpqxx.  No
> doubt both of these things are useful in the end, but as they are right
> now they're a headache waiting to happen.
> 
> Could someone try to address the following issues?
> 
> SSL:
> 
> * A bunch of cryptic configuration files -- what do they do?
> 
> * Weird shell scripts -- what do they do?
> 
> * The shell scripts are written in a completely unportable fashion and
> have inappropriate names (surely PostgreSQL isn't the only application in
> the world that allows to "mkcert").
> 
> * They don't even belong into interfaces.
> 
> * No build instructions, let alone a makefile.

I have requested info from the ssl author with no replies.  Yank it from
CVS or I will do the honors.

> Libpqxx:
> 
> * I'm no C++ whizz, but I guarantee that this coding style is not nearly
> as portable as we've tried to make libpq++ be.  Who wants to answer those
> support calls all over again?
> 
> * What's the deal with libpq++ vs. libpqxx?  Who's going to want to
> explain that to the crowd for the next 5 years?
> 
> * Bogus Automake stuff -- hurts my eyes. ;-)
> 
> * Doxygen -- is that going to be a quasi-required tool now?
> 
> * Bonus points for documentation in DocBook format -- but unfortunately
> version 4.1, and unfortunately not integrated with the rest of the
> documentation set.
> 
> * No build integration.
> 
> * Why are half the text files executable?
> 
> Personally, I'm uneasy about carrying around another interface library
> that appears to have no basis in any sort of standard.

The idea was that someone with more knowledge of PostgreSQL would
integrate the new C++ interface into our build system.  If it doesn't
happen, we will yank it before 7.3.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 9 Jul 2002 23:06:10 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unintegrated stuff in source tree
> > There seems to have been an accumulation lately of stuff that was simply
> > dumped into the source tree without any sort of integration.  I am
> > particularly talking about interfaces/ssl and interfaces/libpqxx.  No
> > doubt both of these things are useful in the end, but as they are right
> > now they're a headache waiting to happen.

> I have requested info from the ssl author with no replies.  Yank it from
> CVS or I will do the honors.

Let's not yank the SSL stuff just yet.  It's all good stuff.  Let's give him
time to reply before 7.3.

Chris


Wed, 10 Jul 2002 11:18:59 +0800
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au>
Re: Unintegrated stuff in source tree
On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Personally, I'm uneasy about carrying around another interface library
> > that appears to have no basis in any sort of standard.

Erm, upon which standards are the other language interfaces based?

> The idea was that someone with more knowledge of PostgreSQL would
> integrate the new C++ interface into our build system.  If it doesn't
> happen, we will yank it before 7.3.

Has the author been given CVS access yet?

Cheers,

Neil

-- 
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

Tue, 9 Jul 2002 23:19:11 -0400
nconway@klamath.dyndns.org (Neil Conway)
Re: Unintegrated stuff in source tree
Neil Conway wrote:
> On Tue, Jul 09, 2002 at 11:06:10PM -0400, Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Personally, I'm uneasy about carrying around another interface library
> > > that appears to have no basis in any sort of standard.
> 
> Erm, upon which standards are the other language interfaces based?
> 
> > The idea was that someone with more knowledge of PostgreSQL would
> > integrate the new C++ interface into our build system.  If it doesn't
> > happen, we will yank it before 7.3.
> 
> Has the author been given CVS access yet?

Yes, he has.  I got him in touch with Marc.  I was just pointing out
that while he knows C++, he needs help getting the connecting stuff
merged to our coding style.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 9 Jul 2002 23:20:47 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unintegrated stuff in source tree
Christopher Kings-Lynne wrote:
> > > There seems to have been an accumulation lately of stuff that was simply
> > > dumped into the source tree without any sort of integration.  I am
> > > particularly talking about interfaces/ssl and interfaces/libpqxx.  No
> > > doubt both of these things are useful in the end, but as they are right
> > > now they're a headache waiting to happen.
> 
> > I have requested info from the ssl author with no replies.  Yank it from
> > CVS or I will do the honors.
> 
> Let's not yank the SSL stuff just yet.  It's all good stuff.  Let's give him
> time to reply before 7.3.

OK, not knowing SSL, I can't judge it.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 9 Jul 2002 23:21:04 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Unintegrated stuff in source tree
On Wed, Jul 10, 2002 at 12:18:16AM +0200, Peter Eisentraut wrote:
> There seems to have been an accumulation lately of stuff that was simply
> dumped into the source tree without any sort of integration.  I am
> particularly talking about interfaces/ssl and interfaces/libpqxx.  No
> doubt both of these things are useful in the end, but as they are right
> now they're a headache waiting to happen.
 
Well, I guess as the author I should comment on the libpqxx side of 
things here.  We decided to drop it into the source tree as-is because 
(1) it's fairly hard to come by the autoconf/automake expertise required 
to make it work from the main source tree's configure script, and (2) not 
all systems or C++ compilers support enough of the Standard to make it 
work, so it ought to remain a separate, optional thing in the beginning.


> Libpqxx:
> 
> * I'm no C++ whizz, but I guarantee that this coding style is not nearly
> as portable as we've tried to make libpq++ be.  Who wants to answer those
> support calls all over again?
 
Please explain.  I'm sure this is not all portable, but what does coding
style have to do with that?  Sure, Microsoft compilers have a problem
with it, but that's just because they don't support the basic concepts
of the language.  We've tried to fix that, but it's very hard to work 
around a bad compiler.  If your compiler doesn't handle C++, don't try 
to compile C++ with it.  I'd try to run it through more critical
compilers, but according to existing compliance tests, gcc 2.95 through
3.1 happpen to be the best compilers around.

As far as I know, libpqxx relies on only two things: first, the C++
standard, and second, libpq.  If your system doesn't support those,
why bother addressing PostgreSQL from C++ in the first place?


> * What's the deal with libpq++ vs. libpqxx?  Who's going to want to
> explain that to the crowd for the next 5 years?
 
Frankly, libpq++ was severely broken.  That's a simple story to tell
the crowd in 5 years' time.  As it turned out, there was no way to
fix it except by writing a completely new library.  Use libpq++ if
you must; libpqxx if you have the choice.  If your compiler only
supports C++ as "A Better C" then libpqxx is not for you.  If there
is some other problem with the code--and I can't say I've heard of any
such case in a while--then it ought to be fixed.


> * Bogus Automake stuff -- hurts my eyes. ;-)
 
Please elaborate.  Like the docs say, the automake stuff was contributed
by external dcvelopers, and I merely tried to edit it.  If you could
just say *what* is so bogus about it, perhaps it could be fixed.  Just
saying that it's bogus and that it hurts your eyes isn't going to help
anyone.  The library has its own automake setup so that it can be
installed separately on systems that support it.  Hopefully someone
will see fit to integrate it into the existing setup at some point.  This
is not proprietary software, after all.


> * Doxygen -- is that going to be a quasi-required tool now?

It comes with docs generated by doxygen.  I don't think that means
that doxygen is "quasi-required" any more than emacs is, just because
some of the text may have been written with it.  If reading HTML is a
problem for you, you have other problems.  Sure, re-generate the docs
with doxygen if you like; you're going to end up with essentially the
same stuff that's bundled with the library.  If you think that's a
useful exercise, you're better off with doxygen.  If you don't, there's
nothing wrong with the way things are.


> * Bonus points for documentation in DocBook format -- but unfortunately
> version 4.1, and unfortunately not integrated with the rest of the
> documentation set.
> 
> * No build integration.

These are on the to-do list, and some are beyond my control so I can't
really address them.  But if you have time to complain about them, 
perhaps you can help fix them as well.  That would be most welcome; I've
essentially been flying blind when writing the docs, mimicking what was
already there.

 
> * Why are half the text files executable?
 
Interesting.  Haven't been able to find a single file with this problem
in the libpqxx distribution archive, so they may have been mangled 
somewhere else.  Where did you find the archive with this problem?


> Personally, I'm uneasy about carrying around another interface library
> that appears to have no basis in any sort of standard.

This suggests that either you haven't actually looked at it, or you're
unfamiliar with C++.  The thing about libpqxx is that it makes database
access adhere to standard C++ interfaces.  So saying that it has "no
basis in any sort of standard" is just plain wrong.  In fact, some C++
programmers have found this tremendously useful, and some have chosen
PostgreSQL over competing databases because of this library.

Now if you want to maintain that it doesn't adhere to an existing, set
standard for C++ database access you may have a point--because there
currently are none (unless you count "industry standards" like the 
pitiful crap MFC users are forced to put up with).  But someday there 
will be, and rest assured that they will look very much like the way 
libpqxx does things, because it sticks very closely to existing STL 
standards.  So far, all C++ experts I've presented this to (including
some involved in the C++ standards process, albeit loosely) have been 
very supportive of libpqxx because of this existing lack of standards, 
and the way libpqxx tries to fit things in.

In my opinion, libpqxx is a good replacement for libpq++.  It does more
to conform to standards, it fixes some serious problems with the original
design, and it makes it easy to write solid programs using PostgreSQL.  In 
the future it will probably be extended to cover other databases as well, 
but for now it's a competitive advantage.  Finally, it fills a void in the
C++ world in a way that may someday define new standards.  I don't think
this would be hard to explain to new or existing programmers.


Jeroen


Wed, 10 Jul 2002 05:38:45 +0200
jtv <jtv@xs4all.nl>
Re: Unintegrated stuff in source tree
On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote:
> > 
> > Has the author been given CVS access yet?
> 
> Yes, he has.  I got him in touch with Marc.  I was just pointing out
> that while he knows C++, he needs help getting the connecting stuff
> merged to our coding style.

Haven't had a reply from Marc yet, so I guess I don't have CVS access
yet.  Anyway, my main problem at this time is know how to begin to
integrate the automake/autoconf stuff into the main source tree.  Can't
say I know a whole lot about these tools or how PostgreSQL uses them,
so as you say I'll need some help making this work in harmony with the 
PostgreSQL stuff.

Any takers?


Jeroen


Wed, 10 Jul 2002 05:48:37 +0200
jtv <jtv@xs4all.nl>
Re: Unintegrated stuff in source tree
On Wed, 10 Jul 2002, jtv wrote:

> On Tue, Jul 09, 2002 at 11:20:47PM -0400, Bruce Momjian wrote:
> > >
> > > Has the author been given CVS access yet?
> >
> > Yes, he has.  I got him in touch with Marc.  I was just pointing out
> > that while he knows C++, he needs help getting the connecting stuff
> > merged to our coding style.
>
> Haven't had a reply from Marc yet, so I guess I don't have CVS access
> yet.  Anyway, my main problem at this time is know how to begin to
> integrate the automake/autoconf stuff into the main source tree.  Can't
> say I know a whole lot about these tools or how PostgreSQL uses them,
> so as you say I'll need some help making this work in harmony with the
> PostgreSQL stuff.
>
> Any takers?

Damn, thanks for teh reminder ... spent today working on the mailing list
lag, and totally forgot about it ... will get that all setup tomorrow,
sorry :(



Wed, 10 Jul 2002 01:17:29 -0300 (ADT)
"Marc G. Fournier" <scrappy@hub.org>
Re: Unintegrated stuff in source tree