Re: Details about libpq cross-version compatibility

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:

#ifndef PG_TYPE_INTERVAL
#define PG_TYPE_INTERVAL 1186
#endif

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?
>
> dbmpgs83x.so 102040 <- diff size expected, as we do not use
> PG_TYPE_INTERVAL
> dbmpgs84x.so 106242 <- starting from here, exactly the same code...
> dbmpgs90x.so 106242
> dbmpgs91x.so 106262
> dbmpgs92x.so 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