Re: Check postgres compile-time options - Mailing list pgsql-general

Martín Marqués wrote:

>El Lun 01 Ago 2005 20:13, Laura Vance escribió:
>
>
>>I've tried other configuration test programs, but none of them seem to
>>connect properly.
>>
>>Is there some incompatibility with this version of iodbc and postgresql
>>7.1.2?
>>
>>
>
>Sorry, I happen to recall that you wanted this to upgrade the PG system. Why
>don't you just use pg_dumpall on the PG 7.1.2 instalation, save the output
>file, upgrade to a newer version (try 8.0.3), and restore the backup with
>psql? Much easier.
>
>
>
I'm not worried about upgrading the database, that part will be easy as
you indicated.  My problem has nothing to do with upgrading the server
side, it's upgrading my applications.  The problem goes something like this:

I installed PostgreSQL back in 1999 for a senior project I was doing in
college.  It came in Linux Mandrake 6.5.  I wrote some wrapper modules
that wrapped the Pg.pm functions with my own functions.  Everything was
good, and I liked the database engine.

I upgraded to Mandrake 7.1 and the respective PostgreSQL database
engine.  Pg.pm was still there, so my apps still worked just fine.
Everything was still good.

I upgraded to Mandrake 8.1 and the respective PostgreSQL database engine
(7.1.2-19mdk).  Pg.pm was still there, and now I decided that I wanted
to write some C++ applications that used PostgreSQL also, so I
researched how to use libpq++.so.  Everything was good.  I even got a
job implementing my software and writing more.

 From there, Mandrake 9.1 had a flaw with script execution, so I
couldn't upgrade to it.

Now I have to upgrade to Fedora Core 4, which uses a much higher version
of PostgreSQL.  Unfortunately the Pg.pm support is gone (it's wrapped by
DBI/DBD, which wasn't that hard to convert my apps, and they work except
for some inconsistent errors that I'll figure out later), and libpq++.so
is gone (which is where the hard part seems to be coming in).  So I have
a choice... I can either rewrite my interface for the new proprietary
objects for PostgreSQL or I can convert my apps to use the ODBC driver
and not have to worry as much on future upgrades.

The problem is that I got bitten in the behind by my choice to avoid
ODBC and use the proprietary PostgreSQL drivers.  It's unfortunate that
they dropped the support, but it's their choice.  The bad part is that
it's the sole thing that's been keeping me from upgrading.

--
Thanks,
Laura Vance
Systems Engineer