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

Re: Details about libpq cross-version compatibility

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Sebastien FLAESCH <sf(at)4js(dot)com>
Cc: pgsql-docs(at)postgresql(dot)org
Subject: Re: Details about libpq cross-version compatibility
Date: 2012-09-13 11:38:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-docs
On 13.09.2012 11:59, Sebastien FLAESCH wrote:
> On 09/13/2012 10:19 AM, Heikki Linnakangas wrote:
>> What I meant is that it probably isn't necessary to ship 5 drivers. The
>> latest version of libpq works against older server versions, so you
>> could just ship one version of the dbmpgs driver (the latest), and it
>> will work with any supported server and libpq version. If it compiles
>> with 8.3 version of libpq, if should work with any newer version at
>> runtime. And if you compile it with 9.2 version of libpq, it should
>> still work at runtime with an older version of libpq, if you refrain
>> from using any new features of libpq.
> Ok... Still you write "should" ;-)
> I guess cross-version compatibility between the PostgreSQL client and
> server versions is not QA tested... is it?
> IMHO, if something is stated in the docs, it must be QA tested...

What's your definition of "QA tested" :-)? There's no official QA 
organization working for the community. There is a suite of automated 
regression tests, but it doesn't do cross-version testing.

I wouldn't worry about it. Historically, there have been very few if any 
bugs that have affected compatibility of a libpq and server of different 
versions. Zero that I can remember, anyway. The protocol has been the 
same for years.

>> However, there might be something else in your driver that's dependent
>> on the server version, like if you construct SQL queries in the driver
>> and you need to use different syntax against different server versions.
>> Even that would probably be better to implement as runtime checks rather
>> than #ifdefs in the driver, so that the latest driver would work against
>> all supported server versions.
> Good point, and in fact, we are not only dependent from the SQL syntax,
> we do also rely on C structures for data types. For ex, starting with 8.4,
> we use the PG_TYPE_INTERVAL type, while with 8.3 we do not use it.
> So we must distinguish 8.3 and 8.4 drivers, and since it's based on C
> structures only this cannot be handled at runtime by a unique driver...

Oh, are you using the psqlODBC driver to connect, not plain libpq? The 
only reference to "PG_TYPE_INTERVAL" I could find with google is in 
psqlODBC sources. I cannot comment on the backwards-compatibility of 
psqlODBC, although I would expect it to be similar to plain libpq's. You 
might want to check with the folk at psql-odbc(at)postgresql(dot)org mailing 
list, though, I'm not very familiar with psqlODBC.

PG_TYPE_INTERVAL is just a #define for the OID of the interval type. 
It's numerical value is 1186, which wasn't used for anything before 8.4, 
and it won't be used for anything else in the future, so you could just 
do something like this in your code:

#define PG_TYPE_INTERVAL 1186

If you're going through the ODBC interface, though, you shouldn't need 
the PostgreSQL header files at all. So I'm a bit confused on what 
exactly you're doing.

> Actually our product is a db programming language called Genero, and this
> language has an INTERVAL type (comes from Informix 4gl / SQL), and if our
> customers want to use such data, they can store values in CHAR(50) with
> PGS 8.3, or (the recommended way of course), use native INTERVALs starting
> with PGS 8.4...

Well, PostgreSQL 8.3 is going to be EOL'd in Feburary 2013, anyway, so I 
don't think it would be a big deal for you to just drop support for < 
8.4 servers.

> Maybe this is a stupid question, but how do you explain that the same
> source code of my driver, compiled with different versions of PGS headers,
> results in different sizes of the shared object?
> 102040 <- diff size expected, as we do not use
> 106242 <- starting from here, exactly the same code...
> 106242
> 106262
> 106290 <- why this diff!?
> Maybe this has something to do with the linker?

Hmm, dunno. Differences in debug symbols maybe; do you still see a 
difference after "strip dbmpgs*.so"?

- Heikki

In response to


pgsql-docs by date

Next:From: Sebastien FLAESCHDate: 2012-09-13 13:10:23
Subject: Re: Details about libpq cross-version compatibility
Previous:From: Sebastien FLAESCHDate: 2012-09-13 08:59:16
Subject: Re: Details about libpq cross-version compatibility

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