Skip site navigation (1) Skip section navigation (2)

ruby-postgres doesn't compile against 8.3!

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: ruby-postgres doesn't compile against 8.3!
Date: 2007-12-07 18:52:00
Message-ID: 1197053520.28804.122.camel@dogma.ljc.laika.com (view raw or flat)
Thread:
Lists: pgsql-interfaces
ruby-postgres is the most widely used PostgreSQL binding for ruby, but
it is unmaintained.

ruby-postgres-0.7.1.tar.gz     compiles fine
ruby-postgres-20051221.tar.gz  doesn't build
ruby-postgres-20060405.tar.gz  doesn't build
ruby-postgres-20060406.tar.gz  doesn't build

The same problems exist for the gems, versions 0.7.1.2006.04.05
0.7.1.2006.04.06.

This could mean that a lot (probably most) of ruby developers will have
a problem upgrading to PostgreSQL 8.3.

This is easy to fix (described below) but unfortunately ruby-postgres is
unmaintained.

I am working on my own fork of the project, ruby-pg, where I maintain
patches against ruby-postgres. It can be found here:

http://rubyforge.org/projects/ruby-pg

I backpatched it to stable, so you can check it out here:

svn co http://ruby-pg.rubyforge.org/svn/branches/stable

and I also released it as a file in the project.

The stable branch is very similar to snapshot 20060406 with a few
updates of my own. It *should* work fine with applications that work
with that snapshot release.

Most of my work on the project has gone into a branch called raw_libpq
(not currently stable), in which I'm rewriting a lot of the code. I'm
trying to streamline the module and make it a fairly thin wrapper around
libpq, that exposes *all* libpq functionality, with a ruby feel to it.
For instance, I raise exceptions on errors, but those exception objects
also hold the PGconn and PGresult objects so that you can access
detailed information if needed.

I would like this new branch to eventually replace the current ruby-
postgres, which does a lot of type conversion magic in C, which ends up
hiding libpq functionality and complicating the C code. Any type
conversion magic should really be done in ruby; there's no reason to do
it in C. I think that's a big part of the reason the current ruby-
postgres is so cluttered.

So, use ruby-pg instead. But please test it first, it hasn't received
much attention outside of my environment.

Regards,
	Jeff Davis

------------------------------------------------
PROBLEM DETAILS:

The snapshot releases of ruby-postgres do not compile against PostgreSQL
8.3. 

This is due to a rather strange sequence in postgres.c:

#ifndef HAVE_PG_ENCODING_TO_CHAR
#define pg_encoding_to_char(x) "SQL_ASCII"
#else
extern char* pg_encoding_to_char(int);
#endif

Apparently, PostgreSQL 8.2 and below did export a function called
pg_encoding_to_char, but did not declare it in any header. PostgreSQL
8.3 does declare it in the header, leading to a "conflicting types"
compilation error.

The quick fix I applied simply removes the declaration (the #else
clause) from postgres.c (which has been renamed to pg.c in my fork).
This leads to an "implicit declaration" compiler warning in 8.2 and
before, but no errors or warnings compiling against 8.3.



pgsql-interfaces by date

Next:From: jing hanDate: 2007-12-11 20:13:47
Subject: If postgres database files are corrupted by power failure, how to check which files are corrupted,
Previous:From: Adam RadłowskiDate: 2007-12-06 21:02:49
Subject: Re: libpq crashing under Vista

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group