Thread: libpq compatibility policy across versions

libpq compatibility policy across versions

From
Sebastien FLAESCH
Date:
Hi all,

We have a libpq client application written in C.

We want to deliver the software so that can it be used with different
PostgreSQL client versions, from 8.3 to 9.3 (and future versions).

So far, we build (compile and link) a binary with each major version
of PostgreSQL (8.3, 8.4, 9.0, 9.1, 9.2, 9.3) - in fact we have shared
libraries (database driver) for each PostgreSQL version.

Is this the proper way, or could we just compile/link with a given
version (9.3) and assume that it's backward compatible with any
prior version such as 8.3 ?

Assuming that we could dynamically load the libpq.so client, search
for existing API symbols and only use them if present?

Is this risky? Do the C headers define C structures that are compatible
between newer and older versions?

I would expect some note about libpq compatibility policy here:

http://www.postgresql.org/docs/9.3/static/libpq-build.html

I can see that the lib version number of libpq.so.x.y changes
for each major version:

/opt3/dbs/pgs/9.2/lib/libpq.so -> libpq.so.5.5
/opt3/dbs/pgs/9.2/lib/libpq.so.5 -> libpq.so.5.5
/opt3/dbs/pgs/9.2/lib/libpq.so.5.5
/opt3/dbs/pgs/9.3.0/lib/libpq.so -> libpq.so.5.6
/opt3/dbs/pgs/9.3.0/lib/libpq.so.5 -> libpq.so.5.6
/opt3/dbs/pgs/9.3.0/lib/libpq.so.5.6

The binaries are dependent from libpq.so.5:

$ ldd -r dbmpgs92x.so...libpq.so.5 => /opt3/dbs/pgs/9.2.3/lib/libpq.so.5 (0xb77bb000)...

What does this mean?

Theoritically, a binary linked in a 9.3 env can use le libpq.so version
of a prior version down to 8.2 ... (8.1 has libpq.so.4)

The main question is about C header compatibility:

- Compile + link with PostgreSQL client version X.Y.?
- What PostgreSQL client version can be used at runtime?

Thanks.
Seb



Re: libpq compatibility policy across versions

From
Sebastien FLAESCH
Date:
Thank you Pavel,

On 10/01/2013 02:28 PM, Pavel Golub wrote:> Yes, you should use the latest client library. It's compatible with> all
priorversions.
 

Just to be clear:

We deliver our product without any PostgreSQL lib included.

Our product installs beside an existing PostgreSQL install, typically
on an application server, where both PostgreSQL client and server are
installed in the same directory.

Imagine for ex a machine with PostgreSQL 8.3 installed.

I am asking how I must compile my source code and how to link, to build
my binary, to be sure that it's compatible with PostgreSQL 8.3, and
any in fact any existing PostgreSQL versions.

Can I for ex, use the V 9.3 headers and library on my dev platform
and then deliver this binary for any PostgreSQL version?

In other words, is the PostgreSQL client C API backward compatible?

Today the lib is stamped with 5 (libpq.so.5), will this never change
in future versions?

Is there a way to detect dynamically the version of the PostgreSQL server?

Thanks!
Seb


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




Re: libpq compatibility policy across versions

From
Pavel Golub
Date:
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




Re: libpq compatibility policy across versions

From
Sebastien FLAESCH
Date:
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
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>




Re: libpq compatibility policy across versions

From
Pavel Golub
Date:
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>>
allprior 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




Re: libpq compatibility policy across versions

From
"Daniel Verite"
Date:
    Sebastien FLAESCH wrote:

> I am asking how I must compile my source code and how to link, to build
> my binary, to be sure that it's compatible with PostgreSQL 8.3, and
> any in fact any existing PostgreSQL versions.

As an example, if your binary calls PQescapeLiteral() and your end user
has libpq.so.5.1 which ships with PostgreSQL 8.3, then the dynamic link
will fail because this version of libpq lacks this function.

Not sure if that disqualifies it as backward compatible. It depends
on your interpretation.

Best regards,
-- 
Daniel
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org



Re: libpq compatibility policy across versions

From
Pavel Golub
Date:
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




Re: libpq compatibility policy across versions

From
Sebastien FLAESCH
Date:
On 10/01/2013 08:50 PM, Daniel Verite wrote:
>     Sebastien FLAESCH wrote:
>
>> I am asking how I must compile my source code and how to link, to build
>> my binary, to be sure that it's compatible with PostgreSQL 8.3, and
>> any in fact any existing PostgreSQL versions.
>
> As an example, if your binary calls PQescapeLiteral() and your end user
> has libpq.so.5.1 which ships with PostgreSQL 8.3, then the dynamic link
> will fail because this version of libpq lacks this function.
>
> Not sure if that disqualifies it as backward compatible. It depends
> on your interpretation.
>
> Best regards,

Thank you Daniel,

I understand you point.

In fact we *could* manage to load dynamically (dlopen/dlsym) libpq.so,
(without a specific .5 version number), then lookup for existing PQ*
symbols, and use them only if they exist.

So in the case you describe, if PQescapeLiteral() does not exist, we
would not use it, assuming that the feature is not mandatory or can
be workaround...

But that's only possible if the PostgreSQL client C API header files
are compatible with all versions. I mean, if I compile with PGS 9.3
(to get the latest C structures / API), it must be compatible with older
client libraries. If structures such as PGconn, PGresult are not
compatible, using an older client lib will potentially memory corruption
and invalid/loss of data or crash the program.

This cross-version compatibility must work for existing and future versions.
I am conscious that this is a strong constraint for PostgreSQL.
And I am not ASKING for it:
We are just evaluating this solution.
My instinct is that it's insane to load dynamically a libpq.so, to
be used with a binary that was compiled with C header of a more
recent version.
But without a clear statement in the docs, I have no counter argument.

Note that, Oracle OCI doc states that when your compile with OCI
headers of 10g, your binary will work with 11g and 12c environments,
without the need to recompile / relink.
Here Oracle 11g / 12c is *backward* compatible with 10g...
And Oracle 10g headers are *upward* compatible with future versions.

See 5.5.2.3 and 5.6 of:
http://docs.oracle.com/cd/E16655_01/server.121/e17642/app.htm#i1006731

But in our case we want to compile with recent .h headers (to use
recent features) and use potentially older libs at runtime..

Thanks.
Seb