Re: Details about libpq cross-version compatibility

On 09/13/2012 01:38 PM, Heikki Linnakangas wrote:
> 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.

By "QA tested", I mean regression tests of course, trying to write and run
as much as possible tests with the different client/server version combined.

> 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.

Ok.

>>> 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.

No no, it's not ODBC, we are using the native libpq API, we always try
to use the closes API provided by the db vendors.

It's a while I did not look deep in our PostgreSQL driver code and I
realize now that we defined PG_TYPE_INTERVAL ourselves in our code.

This is indeed a simple integer and there is not any specific C structure
used either for data: The data is passed and returned as strings.
Sorry for the confusion, this is not usual in other db APIs I am also using
to connect to Informix, Oracle, UDB DB2, SQL Server, etc, where you have
to use structures to hold specific SQL data, as for example in ODBC you
can use structures like TIMESTAMP_STRUCT etc...

So yes, we do:

#define PG_TYPE_INTERVAL 1186

It knowing this, it's probably possible to have a unique driver code that
adapts dynamically to the PostgreSQL server version...

Note that I always wondered why PostgreSQL does not have these type ids
defined in the header files! Is this not weird? Usually APIs define such
constants for db types...
Or do you officially document the numbers like 1186 as type ids?
Will these numbers never change?

>> 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.

Yep, planed so.

>> 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"?

After a strip *.so, the sizes are the same... Good catch!

Sounds like I could give a try to make a unique driver...

Thanks!
Seb