public inbox for [email protected]
help / color / mirror / Atom feedFrom: Heikki Linnakangas <[email protected]>
To: Sebastien FLAESCH <[email protected]>
Cc: [email protected]
Subject: Re: Details about libpq cross-version compatibility
Date: Thu, 13 Sep 2012 11:19:15 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
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.
> 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.
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.
> 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.
- Heikki
view thread (9+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Details about libpq cross-version compatibility
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox