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 at
http://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, Pennsylvania 19026On 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?
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, Pennsylvania 19026
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, Pennsylvania 19026On 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, Pennsylvania 19026got it ... will try and incorporate it and see what I can come up with ...
thanks :)
On Thu, 13 Jun 2002, Bruce Momjian wrote:
Show quoted text
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?
--
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 19026Attachments:
/bjm/difftext/plainDownload
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 configure
The documentation needs to 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, Pennsylvania 19026On 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, Pennsylvania 19026