Обсуждение: Integrating libpqxx
I think libpqxx, the alternative to libpq++, is just about ready for prime time. That means integrating it with the main source tree, I suppose, but I have no idea where to start--particularly because libpqxx has its own configure setup. Anyone who can help me with this? Jeroen PS: find libpqxx source & description athttp://members.ams.chello.nl/j.vermeulen31/
On Wed, 12 Jun 2002 20:29:21 +0200 "Jeroen T. Vermeulen" <jtv@xs4all.nl> wrote: > I think libpqxx, the alternative to libpq++, is just about ready for > prime time. Great -- I like libpqxx a lot, and I'd like to see it in 7.3. We should also probably keep libpq++ around for backward compatibility, but I suppose we can stop distributing it eventually. > That means integrating it with the main source tree, I > suppose, but I have no idea where to start--particularly because libpqxx > has its own configure setup. I took a brief look at libpqxx's configure setup and ISTM that you won't need to do a lot of work to integrate it into the PostgreSQL build system. Users won't need to specify '--with-postgres' anymore, and the rest of the configure options look pretty standard (gnu-ld, pic, etc.) Is there a reason for keeping '--enable-postgres-dialect', when libpqxx is distributed with PostgreSQL? Otherwise, if you put the code into src/interfaces/libpqxx and modify the PostgreSQL build system to be aware of it (as well as removing libpqxx's autoconf stuff), it shouldn't be too difficult. Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote: > > Otherwise, if you put the code into src/interfaces/libpqxx and modify > the PostgreSQL build system to be aware of it (as well as removing > libpqxx's autoconf stuff), it shouldn't be too difficult. One concern I have on this point is that not all platforms are going to be able to build libpqxx. Also, there'd have to be a lot of C++ stuff in the existing config.h which I guess was meant to be C. Anyway, I found I'm not much good with automake and so on. I'm trying to merge the two configure.ins, but I feel I must be missing a lot of details. Jeroen
Jeroen T. Vermeulen wrote: > On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote: > > > > Otherwise, if you put the code into src/interfaces/libpqxx and modify > > the PostgreSQL build system to be aware of it (as well as removing > > libpqxx's autoconf stuff), it shouldn't be too difficult. > > One concern I have on this point is that not all platforms are going to > be able to build libpqxx. Also, there'd have to be a lot of C++ stuff > in the existing config.h which I guess was meant to be C. > > Anyway, I found I'm not much good with automake and so on. I'm trying > to merge the two configure.ins, but I feel I must be missing a lot of > details. 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. -- 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 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 qualityof service for your transactor;- allow notice processors to have C++ linkage;- addtional bits & bobs like field andcolumn 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? Jeroen
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
On Wed, 2002-06-12 at 17:30, Bruce Momjian wrote: > 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. If you "Repocopy" the files, the history will stay intact. Basically move his CVS/ files to your repository, and add appropriate entries stuff. LER > > > -- > 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 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org > -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman wrote: > > > > 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. > If you "Repocopy" the files, the history will stay intact. Basically > move his CVS/ files to your repository, and add appropriate entries > stuff. Ewe, appropriate entries? -- 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 Wed, 2002-06-12 at 19:41, Bruce Momjian wrote: > Larry Rosenman wrote: > > > > > > 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. > > If you "Repocopy" the files, the history will stay intact. Basically > > move his CVS/ files to your repository, and add appropriate entries > > stuff. > > Ewe, appropriate entries? What I did on a RANCID install was to just add the CVS/ stuff, but I'm not sure with your scripts and stuff what else needs done. You might ask Marc Fournier as I think he knows how the FreeBSD folks do RepoCopies. > > -- > 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 -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
> On Wed, 2002-06-12 at 19:41, Bruce Momjian wrote:
>> Ewe, appropriate entries?
I'm thinking we should just import the current state of the files
and not worry about preserving their change history.
regards, tom lane
On Wed, Jun 12, 2002 at 10:41:32PM -0400, Tom Lane wrote: > > I'm thinking we should just import the current state of the files > and not worry about preserving their change history. Fine with me, if that's easier. I just thought it might be "nice to have" but I can't think of any compelling reason to go to any trouble. Jeroen
On Thu, 13 Jun 2002, Jeroen T. Vermeulen wrote: > On Wed, Jun 12, 2002 at 10:41:32PM -0400, Tom Lane wrote: > > > > I'm thinking we should just import the current state of the files > > and not worry about preserving their change history. > > Fine with me, if that's easier. I just thought it might be "nice to have" > but I can't think of any compelling reason to go to any trouble. Jeroen ... can you send me a copy of the CVSROOT for this? Email will work ... if we can, I would like to save the development history, and I *think* I can ...
On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > work ... if we can, I would like to save the development history, and I > *think* I can ... I already sent one to Bruce last night, IIRC. Jeroen
Jeroen T. Vermeulen wrote: > On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > > work ... if we can, I would like to save the development history, and I > > *think* I can ... > > I already sent one to Bruce last night, IIRC. I just bounced it over to Marc. -- 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
got it ... will try and incorporate it and see what I can come up with ... thanks :) On Thu, 13 Jun 2002, Bruce Momjian wrote: > Jeroen T. Vermeulen wrote: > > On Thu, Jun 13, 2002 at 09:15:05AM -0300, Marc G. Fournier wrote: > > > > > > Jeroen ... can you send me a copy of the CVSROOT for this? Email will > > > work ... if we can, I would like to save the development history, and I > > > *think* I can ... > > > > I already sent one to Bruce last night, IIRC. > > I just bounced it over to Marc. > > -- > 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 >
If on one is has outstanding libpq++ patches, I will run libpq++ through my new tools src/tools/pgindent/pgcppindent. It uses astyle. I can also wait for 7.3 beta and run it then. --------------------------------------------------------------------------- Neil Conway wrote: > On Wed, 12 Jun 2002 20:29:21 +0200 > "Jeroen T. Vermeulen" <jtv@xs4all.nl> wrote: > > I think libpqxx, the alternative to libpq++, is just about ready for > > prime time. > > Great -- I like libpqxx a lot, and I'd like to see it in 7.3. We should > also probably keep libpq++ around for backward compatibility, but I > suppose we can stop distributing it eventually. > > > That means integrating it with the main source tree, I > > suppose, but I have no idea where to start--particularly because libpqxx > > has its own configure setup. > > I took a brief look at libpqxx's configure setup and ISTM that you won't > need to do a lot of work to integrate it into the PostgreSQL build system. > Users won't need to specify '--with-postgres' anymore, and the rest of the > configure options look pretty standard (gnu-ld, pic, etc.) > > Is there a reason for keeping '--enable-postgres-dialect', when libpqxx > is distributed with PostgreSQL? > > Otherwise, if you put the code into src/interfaces/libpqxx and modify > the PostgreSQL build system to be aware of it (as well as removing > libpqxx's autoconf stuff), it shouldn't be too difficult. > > Cheers, > > Neil > > -- > Neil Conway <neilconway@rogers.com> > PGP Key ID: DB3C29FC > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- 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 Index: pgconnection.cc =================================================================== RCS file: /cvsroot/pgsql/src/interfaces/libpq++/pgconnection.cc,v retrieving revision 1.14 diff -c -r1.14 pgconnection.cc *** pgconnection.cc 15 Jun 2002 18:49:29 -0000 1.14 --- pgconnection.cc 15 Jun 2002 19:05:11 -0000 *************** *** 1,19 **** /*------------------------------------------------------------------------- ! * ! * FILE ! * pgconnection.cc ! * ! * DESCRIPTION ! * implementation of the PgConnection class. ! * PgConnection encapsulates a frontend to backend connection ! * ! * Copyright (c) 1994, Regents of the University of California ! * ! * IDENTIFICATION ! * $Header: /cvsroot/pgsql/src/interfaces/libpq++/pgconnection.cc,v 1.14 2002/06/15 18:49:29 momjian Exp $ ! * ! *------------------------------------------------------------------------- ! */ #include "pgconnection.h" --- 1,19 ---- /*------------------------------------------------------------------------- ! * ! * FILE ! * pgconnection.cc ! * ! * DESCRIPTION ! * implementation of the PgConnection class. ! * PgConnection encapsulates a frontend to backend connection ! * ! * Copyright (c) 1994, Regents of the University of California ! * ! * IDENTIFICATION ! * $Header: /cvsroot/pgsql/src/interfaces/libpq++/pgconnection.cc,v 1.14 2002/06/15 18:49:29 momjian Exp $ ! * ! *------------------------------------------------------------------------- ! */ #include "pgconnection.h" *************** *** 28,71 **** // **************************************************************** // default constructor -- initialize everything PgConnection::PgConnection() ! : pgConn(NULL), pgResult(NULL), pgCloseConnection(false) {} // constructor -- checks environment variable for database name // Now uses PQconnectdb PgConnection::PgConnection(const char* conninfo) ! : pgConn(NULL), pgResult(NULL), pgCloseConnection(true) { ! // Connect to the database ! Connect(conninfo); } // destructor - closes down the connection and cleanup PgConnection::~PgConnection() { ! // Close the connection only if needed ! // This feature will most probably be used by the derived classes that ! // need not close the connection after they are destructed. ! CloseConnection(); } // PgConnection::CloseConnection() // close down the connection if there is one ! void PgConnection::CloseConnection() { ! // if the connection is open, close it first ! if (pgCloseConnection) { ! if (pgResult) ! PQclear(pgResult); ! pgResult = NULL; ! if (pgConn) ! PQfinish(pgConn); ! pgConn = NULL; ! pgCloseConnection = false; ! } } --- 28,73 ---- // **************************************************************** // default constructor -- initialize everything PgConnection::PgConnection() ! : pgConn(NULL), pgResult(NULL), pgCloseConnection(false) {} // constructor -- checks environment variable for database name // Now uses PQconnectdb + PgConnection::PgConnection(const char* conninfo) ! : pgConn(NULL), pgResult(NULL), pgCloseConnection(true) { ! // Connect to the database ! Connect(conninfo); } // destructor - closes down the connection and cleanup PgConnection::~PgConnection() { ! // Close the connection only if needed ! // This feature will most probably be used by the derived classes that ! // need not close the connection after they are destructed. ! CloseConnection(); } // PgConnection::CloseConnection() // close down the connection if there is one ! void PgConnection::CloseConnection() { ! // if the connection is open, close it first ! if (pgCloseConnection) ! { ! if (pgResult) ! PQclear(pgResult); ! pgResult = NULL; ! if (pgConn) ! PQfinish(pgConn); ! pgConn = NULL; ! pgCloseConnection = false; ! } } *************** *** 73,112 **** // establish a connection to a backend ConnStatusType PgConnection::Connect(const char conninfo[]) { ! // if the connection is open, close it first ! CloseConnection(); ! // Connect to the database ! pgConn = PQconnectdb(conninfo); ! // Now we have a connection we must close (even if it's bad!) ! pgCloseConnection = true; ! ! // Status will return either CONNECTION_OK or CONNECTION_BAD ! return Status(); } // PgConnection::status -- return connection or result status ConnStatusType PgConnection::Status() const { ! return PQstatus(pgConn); } // PgConnection::exec -- send a query to the backend ExecStatusType PgConnection::Exec(const char* query) { ! // Clear the result stucture if needed ! if (pgResult) ! PQclear(pgResult); ! ! // Execute the given query ! pgResult = PQexec(pgConn, query); ! ! // Return the status ! if (pgResult) ! return PQresultStatus(pgResult); ! else ! return PGRES_FATAL_ERROR; } // Return true if the Postgres command was executed OK --- 75,114 ---- // establish a connection to a backend ConnStatusType PgConnection::Connect(const char conninfo[]) { ! // if the connection is open, close it first ! CloseConnection(); ! ! // Connect to the database ! pgConn = PQconnectdb(conninfo); ! // Now we have a connection we must close (even if it's bad!) ! pgCloseConnection = true; ! // Status will return either CONNECTION_OK or CONNECTION_BAD ! return Status(); } // PgConnection::status -- return connection or result status ConnStatusType PgConnection::Status() const { ! return PQstatus(pgConn); } // PgConnection::exec -- send a query to the backend ExecStatusType PgConnection::Exec(const char* query) { ! // Clear the result stucture if needed ! if (pgResult) ! PQclear(pgResult); ! ! // Execute the given query ! pgResult = PQexec(pgConn, query); ! ! // Return the status ! if (pgResult) ! return PQresultStatus(pgResult); ! else ! return PGRES_FATAL_ERROR; } // Return true if the Postgres command was executed OK *************** *** 125,158 **** // PgConnection::notifies() -- returns a notification from a list of unhandled notifications PGnotify* PgConnection::Notifies() { ! return PQnotifies(pgConn); } // From Integer To String Conversion Function string PgConnection::IntToString(int n) { ! char buffer [4*sizeof(n) + 2]; ! sprintf(buffer, "%d", n); ! return buffer; } bool PgConnection::ConnectionBad() const ! { ! return Status() == CONNECTION_BAD; } const char* PgConnection::ErrorMessage() const ! { ! return (const char *)PQerrorMessage(pgConn); } ! const char* PgConnection::DBName() const ! { ! return (const char *)PQdb(pgConn); } PQnoticeProcessor PgConnection::SetNoticeProcessor(PQnoticeProcessor proc, void *arg) { ! return PQsetNoticeProcessor(pgConn, proc, arg); } --- 127,160 ---- // PgConnection::notifies() -- returns a notification from a list of unhandled notifications PGnotify* PgConnection::Notifies() { ! return PQnotifies(pgConn); } // From Integer To String Conversion Function string PgConnection::IntToString(int n) { ! char buffer [4*sizeof(n) + 2]; ! sprintf(buffer, "%d", n); ! return buffer; } bool PgConnection::ConnectionBad() const ! { ! return Status() == CONNECTION_BAD; } const char* PgConnection::ErrorMessage() const ! { ! return (const char *)PQerrorMessage(pgConn); } ! const char* PgConnection::DBName() const ! { ! return (const char *)PQdb(pgConn); } PQnoticeProcessor PgConnection::SetNoticeProcessor(PQnoticeProcessor proc, void *arg) { ! return PQsetNoticeProcessor(pgConn, proc, arg); }
OK, I have added this to our CVS under interfaces/libpqxx. I have not migrated over the CVS history. If we have questions about the code, we know who to ask. ;-) Libpqxx still needs to be integrated:The 'configure' tests need to be merged into our main configureThe documentation needsto be merged into our SGML docs.The makefile structure needs to be merged into /interfaces. Jeroen, do you have PostgreSQL CVS access yet? If not, we need to get you that. --------------------------------------------------------------------------- Jeroen T. Vermeulen wrote: > On Wed, Jun 12, 2002 at 04:04:36PM -0400, Neil Conway wrote: > > > > Otherwise, if you put the code into src/interfaces/libpqxx and modify > > the PostgreSQL build system to be aware of it (as well as removing > > libpqxx's autoconf stuff), it shouldn't be too difficult. > > One concern I have on this point is that not all platforms are going to > be able to build libpqxx. Also, there'd have to be a lot of C++ stuff > in the existing config.h which I guess was meant to be C. > > Anyway, I found I'm not much good with automake and so on. I'm trying > to merge the two configure.ins, but I feel I must be missing a lot of > details. > > > Jeroen > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster > -- 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 Tue, Jul 02, 2002 at 02:05:57PM -0400, Bruce Momjian wrote: > > Jeroen, do you have PostgreSQL CVS access yet? If not, we need to get > you that. Don't have it yet, so please do! Jeroen
Is it included now in the main build process? If so, I'll test it on FreeBSD/Alpha. > Libpqxx still needs to be integrated: > > The 'configure' tests need to be merged into our main configure > The documentation needs to be merged into our SGML docs. > The makefile structure needs to be merged into /interfaces. Chris
Christopher Kings-Lynne wrote: > Is it included now in the main build process? If so, I'll test it on > FreeBSD/Alpha. > > > Libpqxx still needs to be integrated: > > > > The 'configure' tests need to be merged into our main configure > > The documentation needs to be merged into our SGML docs. > > The makefile structure needs to be merged into /interfaces. > No, currently disabled in the build. You can go into libpqxx and run configure and make and that should work. -- 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