Re: libpq compatibility policy across versions
От | Sebastien FLAESCH |
---|---|
Тема | Re: libpq compatibility policy across versions |
Дата | |
Msg-id | 524AE9DC.4020407@4js.com обсуждение исходный текст |
Ответ на | libpq compatibility policy across versions (Sebastien FLAESCH <sf@4js.com>) |
Ответы |
Re: libpq compatibility policy across versions
|
Список | pgsql-interfaces |
Thank you Pavel, I appreciate your help, but I would however prefer a clear statement from the PostgreSQL C API developpers, written in the doc... ;-) We have a commercial software: not sure we can deliver the PostgreSQL client library in our packages, regarding open source license policy. We don't want to make the sources of our product public. Further, I don't like to ship other software libs in our product, typically you want to use what is installed on the system. If there is a bug in the PostgreSQL client lib, it's up to the user to install the new lib that fixes the bug, without asking us to rebuild a package with the new pgs lib. Nothing new here, just traditional shared lib usage and dependency. Yes, my instinct is also to use the C headers matching the lib version used at runtime, we do this for now... But some people think it's possible to provide a unique binary for all versions of PostgreSQL, so I ask for a clear rule for the PostgreSQL C API. Note also that we want to use the latest version, to get the latest features with new C structures and defines... So typically, we would compile with PostgreSQL 9.3 headers... Seb 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 >>> >>> >>> >>> >>> > > > > > >
В списке pgsql-interfaces по дате отправления: