Thread: Integrating libpqxx

Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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/




Re: Integrating libpqxx

From
Neil Conway
Date:
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


Re: Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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



Re: Integrating libpqxx

From
Bruce Momjian
Date:
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
 


Re: Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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



Re: Integrating libpqxx

From
Bruce Momjian
Date:
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
 


Re: Integrating libpqxx

From
Larry Rosenman
Date:
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



Re: Integrating libpqxx

From
Bruce Momjian
Date:
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
 


Re: Integrating libpqxx

From
Larry Rosenman
Date:
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



Re: Integrating libpqxx

From
Tom Lane
Date:
> 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


Re: Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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



Re: Integrating libpqxx

From
"Marc G. Fournier"
Date:
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 ...




Re: Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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



Re: Integrating libpqxx

From
Bruce Momjian
Date:
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
 


Re: Integrating libpqxx

From
"Marc G. Fournier"
Date:
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
>



Re: Integrating libpqxx

From
Bruce Momjian
Date:
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);
  }


Re: Integrating libpqxx

From
Bruce Momjian
Date:
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
 




Re: Integrating libpqxx

From
"Jeroen T. Vermeulen"
Date:
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





Re: Integrating libpqxx

From
"Christopher Kings-Lynne"
Date:
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





Re: Integrating libpqxx

From
Bruce Momjian
Date:
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