Re: Integrating libpqxx - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Integrating libpqxx
Date
Msg-id 200206122230.g5CMU6f18293@candle.pha.pa.us
Whole thread Raw
In response to Re: Integrating libpqxx  ("Jeroen T. Vermeulen" <jtv@xs4all.nl>)
Responses Re: Integrating libpqxx  (Larry Rosenman <ler@lerctr.org>)
List pgsql-hackers
Jeroen T. Vermeulen wrote:
> On Wed, Jun 12, 2002 at 05:48:46PM -0400, Bruce Momjian wrote:
> > 
> > I can add it to CVS as interfaces/libpqxx and we can then let others
> > merge your configure tests into our main configure.  Let me know when
> > you want it dumped into CVS.
> 
> Might as well do it right now, with 0.5.2.  We'll call that 1.0, and 
> leave the more radical future plans for 2.0.  
> 
> There are some things I'd like to do in future 1.x releases that will 
> affect the interface:
>  - nonblocking operation, probably as a latency-hiding tuple stream;
>  - change the way you select the quality of service for your transactor;
>  - allow notice processors to have C++ linkage;
>  - addtional bits & bobs like field and column iterators.
> 
> OTOH there's no point in delaying 1.0 forever I guess.
> 
> FWIW, I'm thinking of doing at least one of the following in 2.0:
>  - an easy-to-use but intrusive object persistence layer; 
>  - offload some of the work to BOOST if possible;
>  - adapt the interface to be more database-portable.
> 
> But back to 1.0...  Would it be a useful idea to also integrate my own
> CVS history into the main tree?  Or should I just keep developing in
> my local tree and submit from there?

I think we will just give you CVS access.  Not sure how to get the CVS
history.  I think if you send me the CVS root I can use CVS import to
load 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,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Feature request: Truncate table
Next
From: "Ken Hirsch"
Date:
Subject: Re: New string functions; initdb required