Re: Details about libpq cross-version compatibility

On 09/13/2012 10:19 AM, Heikki Linnakangas wrote:
> On 13.09.2012 10:46, Sebastien FLAESCH wrote:
>> Thank you Heikki for your answer!
>>
>> I can write a paragraph, (hence I did never do that => where can I find
>> info to contribute on the doc?)
>
> Just follow the style and language of the rest of the docs the best that
> you can. If you can submit the changes as a patch against the SGML docs
> in the source repository, that would be great, but I can also easily
> convert it to that format if you just post the suggested text itself in
> an email.

ok...

>> But so far it's not quite clear to me:
>>
>> You write "That really shouldn't be necessary", when I write that we have
>> to ship different drivers for each major PostgreSQL version...
>>
>> Is this what I should document? Based on assumptions?
>>
>> Further: Today we use a simple naming convention:
>>
>> dbmpgs83x => for PostgreSQL 8.3.x
>> dbmpgs84x => for PostgreSQL 8.4.x
>> dbmpgs90x => for PostgreSQL 9.0.x
>> dbmpgs91x => for PostgreSQL 9.1.x
>> dbmpgs92x => for PostgreSQL 9.2.x
>>
>> While we need to ship 5 drivers, this is clear and simple to understand.
>
> 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...

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

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

>> If a future major version (for ex 9.3) implements a new strategic feature
>> that makes libpq headers incompatible with prior versions, what shall we
>> do with our convention? Shall we ship 9.x (where 0<=x<=2) drivers and
>> 9.3+
>> drivers? What if a next major version implements again another feature
>> that makes headers incompatible again?
>
> Yes, however, we try hard to avoid doing such incompatible changes to
> libpq. In fact, I don't recall any such changes in the project history.
> Backwards-compatibility of libpq is important.
>
> If you actually use the new features added at a later libpq library,
> then you obviously need a new version of the library, but if you write
> your client program to the lowest common denominator, it will work with
> any version of libpq. For example, the libpq sample programs in that
> come with the server sources in src/test/examples all work with a
> different libpq version. If you take the 9.2 versions of those and run
> them with 8.3 version of libpq, they work, and vice versa.

I see, but as you can imagine with the INTERVAL case, we cannot use the
lowest common denominator...

Further:

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?

Thanks for your help... really appreciated.
Seb