Re: libpq compatibility policy across versions
От | Pavel Golub |
---|---|
Тема | Re: libpq compatibility policy across versions |
Дата | |
Msg-id | 3810480384.20131002103412@gf.microolap.com обсуждение исходный текст |
Ответ на | Re: libpq compatibility policy across versions (Sebastien FLAESCH <sf@4js.com>) |
Список | pgsql-interfaces |
Hello, Sebastien. You wrote: SF> Thank you Pavel, I appreciate your help, but I would however prefer a clear SF> statement from the PostgreSQL C API developpers, written in the doc... ;-) Fare enough. :) SF> We have a commercial software: not sure we can deliver the PostgreSQL client SF> library in our packages, regarding open source license policy. We don't want SF> to make the sources of our product public. We have commercial software too. And we ship it with client library. It's all OK woth license. SF> Further, I don't like to ship other software libs in our product, typically SF> you want to use what is installed on the system. SF> If there is a bug in the PostgreSQL client lib, it's up to the user to install SF> the new lib that fixes the bug, without asking us to rebuild a package with SF> the new pgs lib. SF> Nothing new here, just traditional shared lib usage and dependency. SF> Yes, my instinct is also to use the C headers matching the lib version used SF> at runtime, we do this for now... SF> But some people think it's possible to provide a unique binary for all versions SF> of PostgreSQL, so I ask for a clear rule for the PostgreSQL C API. SF> Note also that we want to use the latest version, to get the latest features SF> with new C structures and defines... SF> So typically, we would compile with PostgreSQL 9.3 headers... SF> Seb SF> On 10/01/2013 04:38 PM, Pavel Golub wrote: >> Hello, Sebastien. >> >> You wrote: >> >> SF> Thank you Pavel, >> >> SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >> >> Yes, you should use the latest client library. It's compatible with >> >> all prior versions. >> >> SF> Just to be clear: >> >> SF> We deliver our product without any PostgreSQL lib included. >> >> Well, I prefer to deploy products with the latest lib included. Thus >> I'm absolutely sure in the environment used. >> >> SF> Our product installs beside an existing PostgreSQL install, typically >> SF> on an application server, where both PostgreSQL client and server are >> SF> installed in the same directory. >> >> That's possible of course, but there are a lot of issues you may face >> with IMHO >> >> SF> Imagine for ex a machine with PostgreSQL 8.3 installed. >> >> SF> I am asking how I must compile my source code and how to link, to build >> SF> my binary, to be sure that it's compatible with PostgreSQL 8.3, and >> SF> any in fact any existing PostgreSQL versions. >> >> SF> Can I for ex, use the V 9.3 headers and library on my dev platform >> SF> and then deliver this binary for any PostgreSQL version? >> >> SF> In other words, is the PostgreSQL client C API backward compatible? >> >> I'm not sure it is. >> >> >> SF> Today the lib is stamped with 5 (libpq.so.5), will this never change >> SF> in future versions? >> >> SF> Is there a way to detect dynamically the version of the PostgreSQL server? >> >> "SELECT version()" will do the trick using direct SQL. >> http://www.postgresql.org/docs/9.3/static/functions-info.html >> >> PQserverVersion - will help you if you need an integer representing the backend version. >> http://www.postgresql.org/docs/9.3/static/libpq-status.html >> >> >> >> SF> Thanks! >> SF> Seb >> >> >> SF> On 10/01/2013 02:28 PM, Pavel Golub wrote: >>>> Hello, Sebastien. >>>> >>>> You wrote: >>>> >>>> SF> Hi all, >>>> >>>> SF> We have a libpq client application written in C. >>>> >>>> SF> We want to deliver the software so that can it be used with different >>>> SF> PostgreSQL client versions, from 8.3 to 9.3 (and future versions). >>>> >>>> SF> So far, we build (compile and link) a binary with each major version >>>> SF> of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared >>>> SF> libraries (database driver) for each PostgreSQL version. >>>> >>>> SF> Is this the proper way, or could we just compile/link with a given >>>> SF> version (9.3) and assume that it's backward compatible with any >>>> SF> prior version such as 8.3 ? >>>> >>>> Yes, you should use the latest client library. It's compatible with >>>> all prior versions. >>>> >>>> SF> Assuming that we could dynamically load the libpq.so client, search >>>> SF> for existing API symbols and only use them if present? >>>> >>>> SF> Is this risky? Do the C headers define C structures that are compatible >>>> SF> between newer and older versions? >>>> >>>> SF> I would expect some note about libpq compatibility policy here: >>>> >>>> SF> http://www.postgresql.org/docs/9.3/static/libpq-build.html >>>> >>>> SF> I can see that the lib version number of libpq.so.x.y changes >>>> SF> for each major version: >>>> >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.2/lib/libpq.so.5.5 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6 >>>> SF> /opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6 >>>> >>>> SF> The binaries are dependent from libpq.so.5: >>>> >>>> SF> $ ldd -r dbmpgs92x.so >>>> SF> ... >>>> SF> libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000) >>>> SF> ... >>>> >>>> SF> What does this mean? >>>> >>>> SF> Theoritically, a binary linked in a 9.3 env can use le libpq.so version >>>> SF> of a prior version down to 8.2 ... (8.1 has libpq.so.4) >>>> >>>> SF> The main question is about C header compatibility: >>>> >>>> SF> - Compile + link with PostgreSQL client version X.Y.? >>>> SF> - What PostgreSQL client version can be used at runtime? >>>> >>>> SF> Thanks. >>>> SF> Seb >>>> >>>> >>>> >>>> >>>> >> >> >> >> >> >> -- With best wishes,Pavel mailto:pavel@gf.microolap.com
В списке pgsql-interfaces по дате отправления: