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
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
