Thread: libpqxx update
I've just made some updates to libpqxx, my new C++ frontend API to postgresql. Anybody who is interested, please get the source code off my homepage: http://members.ams.chello.nl/j.vermeulen31/ Unpack the tarball (it will create its own directory), cd into it, enter the Makefile to your liking, and run make. The example programs (test*.cc) will show how easy the library is to use. Recent changes: - Revamped trigger notification system.- Some SGML documentation.- Enhanced error checking.- Regression test added to Makefile. Tom, Bruce, perhaps this is worth incorporating into the postgresql source tree at some point? Jeroen
jtv <jtv@xs4all.nl> writes:
> Tom, Bruce, perhaps this is worth incorporating into the postgresql source
> tree at some point?
Sure, we could talk about that. 7.2 is feature-frozen of course, but
for some future release ...
regards, tom lane
On Sat, Dec 01, 2001 at 07:08:54PM -0500, Tom Lane wrote: > > Sure, we could talk about that. 7.2 is feature-frozen of course, but > for some future release ... Great. My main concern is with compiler portability. I don't have access to a lot of compilers or platforms right now, and I'm sure my code will break on various compilers depending on how much of the C++ standard they support. One of my design parameters was to just require the support I needed and not bother too much with backward compilers. I can see that could be a problem when integrating into the source tree; I don't expect to be able to kludge around all compiler shortfalls. Assuming this code is integrated, is not having libpqxx available on all platforms that PostgreSQL runs on acceptable? Or does it become acceptable when there is good reason to suppose that the remaining platforms can be supported later on as their compilers improve?
> On Sat, Dec 01, 2001 at 07:08:54PM -0500, Tom Lane wrote: > > > > Sure, we could talk about that. 7.2 is feature-frozen of course, but > > for some future release ... > > Great. My main concern is with compiler portability. I don't have access > to a lot of compilers or platforms right now, and I'm sure my code will > break on various compilers depending on how much of the C++ standard they > support. > > One of my design parameters was to just require the support I needed and > not bother too much with backward compilers. I can see that could be a > problem when integrating into the source tree; I don't expect to be able > to kludge around all compiler shortfalls. Assuming this code is > integrated, is not having libpqxx available on all platforms that > PostgreSQL runs on acceptable? Or does it become acceptable when there > is good reason to suppose that the remaining platforms can be supported > later on as their compilers improve? We will get them tested on all our platforms as part of 7.3 development and get it working on all of them. Assuming you can stick around to help us resolve problems, by the time we are done, it will be portable. :-) -- 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, Pennsylvania19026
On Mon, Dec 03, 2001 at 11:21:43AM -0500, Bruce Momjian wrote: > > We will get them tested on all our platforms as part of 7.3 development > and get it working on all of them. Assuming you can stick around to > help us resolve problems, by the time we are done, it will be portable. :-) Hope you're right of course. :-) OTOH I have no idea how far along most the various C++ on the various platforms are w.r.t. the Standard. It can be very hard (if not downright impossible) to fix problems in that area.
jtv wrote: > I've just made some updates to libpqxx, my new C++ frontend API to postgresql. > Anybody who is interested, please get the source code off my homepage: > > http://members.ams.chello.nl/j.vermeulen31/ > > Unpack the tarball (it will create its own directory), cd into it, enter the > Makefile to your liking, and run make. The example programs (test*.cc) will > show how easy the library is to use. > > Recent changes: > > - Revamped trigger notification system. > - Some SGML documentation. > - Enhanced error checking. > - Regression test added to Makefile. > > Tom, Bruce, perhaps this is worth incorporating into the postgresql source > tree at some point? Yes, let us know when you would like to move it over. We have always wanted a better C++ interface. -- 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, Pennsylvania19026
On Fri, Feb 22, 2002 at 03:08:32PM -0500, Bruce Momjian wrote: > > Yes, let us know when you would like to move it over. We have always > wanted a better C++ interface. There are two more things I'd like to do before inclusion: 1. Write exhaustive unit tests, so _all_ methods are exercised. 2. Port the Little Brother network monitoring tool to libpqxx. I don't think those will be all that much work, so perhaps we can do both efforts in parallel, starting right now? Jeroen
On Sat, Feb 23, 2002 at 05:52:14PM +0100, jtv wrote: > > There are two more things I'd like to do before inclusion: > > 1. Write exhaustive unit tests, so _all_ methods are exercised. I've begun this job, achieving full test coverage for the Connection and Trigger classes and documenting coverage for Cursor. The Result class is going to be the big one. Improved test coverage has revealed no bugs so far, but I do expect to sleep a little better tonight. Jeroen -- http://members.ams.chello.nl/j.vermeulen31/
On Sun, Feb 24, 2002 at 02:43:04AM +0100, jtv wrote: > > Improved test coverage has revealed no bugs so far, but I do expect to > sleep a little better tonight. Test coverage has been extended further--and has now revealed a fairly serious bug in implicit abort I introduced during recent maintenance. Latest version (without the bug, naturally) has been uploaded to my home page: http://members.ams.chello.nl/j.vermeulen31/proj-libpqxx.html Jeroen