Thread: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Wolfgang Rißler
Date:
Hello community,

we are (unfortunately) on windows with our DB and our application.
Now we want to switch to a new version of Postgres, because we want to 
use logical replication (to replace our old Postgres 8.3 with 
slony-replication).

The problem is, that our application (IDE MS-VisualStudio, C++) has to 
be 32bit, because of some old 32bit-dll's, which we cant kick out at the 
moment.
So I compiled a libpqxx with the last 32bit libpq (which is v10).

I tried to access a PostgresDB 64bit v10, and it worked very nice.
So my question is, could (or should) we rather use PostgresDB v13 (to 
get the newest) or should we stay on PostgresDB v10 (to be more 
compatible to our libpq/libpqxx).

Thank you,
woelfchen72

-- 

- may the source be with you -



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Wolfgang Rißler
Date:
Am 30.04.2021 um 13:00 schrieb Laurenz Albe:
> On Fri, 2021-04-30 at 10:49 +0200, Wolfgang Rißler wrote:
>> we are (unfortunately) on windows with our DB and our application.
>> Now we want to switch to a new version of Postgres, because we want to
>> use logical replication (to replace our old Postgres 8.3 with
>> slony-replication).
>>
>> The problem is, that our application (IDE MS-VisualStudio, C++) has to
>> be 32bit, because of some old 32bit-dll's, which we cant kick out at the
>> moment.
>> So I compiled a libpqxx with the last 32bit libpq (which is v10).
>>
>> I tried to access a PostgresDB 64bit v10, and it worked very nice.
>> So my question is, could (or should) we rather use PostgresDB v13 (to
>> get the newest) or should we stay on PostgresDB v10 (to be more
>> compatible to our libpq/libpqxx).
> 
> Use the latest PostgreSQL client if you can, it shouldn't be a problem.
> 
> Yours,
> Laurenz Albe
> 

Thanks for answering, but
I didn't ask for a PostgreSQL client. I asked for the c-language-lib 
libpq. (which is maybe used by some clients).
I would use the latest libpq, but I cant, because our c++-project stucks 
in 32bit architecture. The latest 32bit pqlib is that from v10.

Can I access a PostgreSQL v13 Database with this pqlib safely?



-- 

Wolfgang Rißler
mailto: wolfgang.rissler@freenet.de
mobil: +49 1520 9191759
- may the source be with you -



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Wolfgang Rißler
Date:
Am 30.04.2021 um 13:41 schrieb Laurenz Albe:
 > Please reply to the list> Sorry my mistake, I fixed this.

 > On Fri, 2021-04-30 at 13:20 +0200, Wolfgang Rißler wrote:
 >> Thanks for answering, but
 >> I didn't ask for a PostgreSQL client. I asked for the c-language-lib
 >> libpq. (which is maybe used by some clients).
 >
 > That *is* a client (in my book).
Ok, I agree. Sorry for admonition.

 >
 >> I would use the latest libpq, but I cant, because our c++-project stucks
 >> in 32bit architecture. The latest 32bit pqlib is that from v10.
 >
 > You can build libpq on a 32-bit system.  No problem.
Yes it is: I'm missing the experience. Until now I took the libpq from 
the actual WindowsInstaller-installation from EDB. But they dont provide 
32bit anymore. PG10 ist the last one.
Compiling a libpqxx on this base with VisualStudio and CMake works like 
a charm.
Can you give a hint, how to build a pqlib v13 x86 in windows with VS?

 >
 >> Can I access a PostgreSQL v13 Database with this pqlib safely?
 >
 > Yes.
This makes me happy.
Thank you.

[snip]


-- 

- may the source be with you -



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Tom Lane
Date:
=?UTF-8?Q?Wolfgang_Ri=c3=9fler?= <wolfgang.rissler@freenet.de> writes:
> The problem is, that our application (IDE MS-VisualStudio, C++) has to 
> be 32bit, because of some old 32bit-dll's, which we cant kick out at the 
> moment.
> So I compiled a libpqxx with the last 32bit libpq (which is v10).

Uh ... what's this about "last 32-bit libpq"?

I can believe that a particular packager (EDB, say) might not be shipping
prebuilt 32-bit binaries anymore.  But if you are in a position to compile
your own libraries then you can certainly build any release you want as
32-bit.

I would recommend trying to use a reasonably late-vintage libpq; we do
fix bugs in it on a regular basis.

The common stumbling block for cross-version situations is that the
client makes assumptions about system catalog contents that are not
valid in some other server release.  libpq proper doesn't really touch
the catalogs, so it's mostly impervious to that problem; but you'll need
to test your applications.

            regards, tom lane



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Wolfgang Rißler
Date:
Am 30.04.2021 um 16:16 schrieb Tom Lane:
> =?UTF-8?Q?Wolfgang_Ri=c3=9fler?= <wolfgang.rissler@freenet.de> writes:
>> The problem is, that our application (IDE MS-VisualStudio, C++) has to
>> be 32bit, because of some old 32bit-dll's, which we cant kick out at the
>> moment.
>> So I compiled a libpqxx with the last 32bit libpq (which is v10).
> 
> Uh ... what's this about "last 32-bit libpq"?

Ok, I meant, the last ready to use packaged 32-bit libpq from EDB (~_0).

> 
> I can believe that a particular packager (EDB, say) might not be shipping
> prebuilt 32-bit binaries anymore.  But if you are in a position to compile
> your own libraries then you can certainly build any release you want as
> 32-bit.

This is my problem, I completely dont know, how to start compiling my 
own actual 32bit libpq on windows (and I would like to do it with VS 2019).
For libpqxx there have been some hints how to do so in the past, and now 
there is a complete project, which deals with compiling it on windows 
with VS and CMake. But I didnt find such hints for libpq or the whole 
postgresDB.
Or is there another provider, who supplys V13 32bit binary installers 
for Windows?


> 
> I would recommend trying to use a reasonably late-vintage libpq; we do
> fix bugs in it on a regular basis.


> 
> The common stumbling block for cross-version situations is that the
> client makes assumptions about system catalog contents that are not
> valid in some other server release.  libpq proper doesn't really touch
> the catalogs, so it's mostly impervious to that problem; but you'll need
> to test your applications.

Of course we'll do. One thing is, that we load and write bytea's. And as 
I read, there have been some changes. All other Operations are less 
problematic.

Thank you

-- 

- may the source be with you -



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Adrian Klaver
Date:
On 5/1/21 3:59 AM, Wolfgang Rißler wrote:

> This is my problem, I completely dont know, how to start compiling my 
> own actual 32bit libpq on windows (and I would like to do it with VS 2019).
> For libpqxx there have been some hints how to do so in the past, and now 
> there is a complete project, which deals with compiling it on windows 
> with VS and CMake. But I didnt find such hints for libpq or the whole 
> postgresDB.

Have you looked at below?:

https://www.postgresql.org/docs/current/install-windows.html


> 
> Thank you
> 


-- 
Adrian Klaver
adrian.klaver@aklaver.com



Re: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)

From
Wolfgang Rißler
Date:
Am 01.05.2021 um 18:26 schrieb Adrian Klaver:
> On 5/1/21 3:59 AM, Wolfgang Rißler wrote:
> 
>> This is my problem, I completely dont know, how to start compiling my 
>> own actual 32bit libpq on windows (and I would like to do it with VS 
>> 2019).
>> For libpqxx there have been some hints how to do so in the past, and 
>> now there is a complete project, which deals with compiling it on 
>> windows with VS and CMake. But I didnt find such hints for libpq or 
>> the whole postgresDB.
> 
> Have you looked at below?:
> 
> https://www.postgresql.org/docs/current/install-windows.html
> 

Stupid me, I've over overlooked this. So I will collect all the tools 
together and give it a try.

Thank you.


-- 

- may the source be with you -



Am 03.05.2021 um 10:41 schrieb Laurenz Albe:
> On Sat, 2021-05-01 at 12:59 +0200, Wolfgang Rißler wrote:
>> Am 30.04.2021 um 16:16 schrieb Tom Lane:
>>> I would recommend trying to use a reasonably late-vintage libpq; we do
>>> fix bugs in it on a regular basis.
>>> The common stumbling block for cross-version situations is that the
>>> client makes assumptions about system catalog contents that are not
>>> valid in some other server release.  libpq proper doesn't really touch
>>> the catalogs, so it's mostly impervious to that problem; but you'll need
>>> to test your applications.
>>
>> Of course we'll do. One thing is, that we load and write bytea's. And as
>> I read, there have been some changes. All other Operations are less
>> problematic.
> 
> Version 9.0 changed the default "bytea" output format to hexadecimal.
> If you want the old text output format, set "bytea_output" to "escape".
> 
> If you output "bytea"s in binary form, nothing has changed.
> 
This is a useful hint. I did this already in my PG10 <-> libpq10(x86) 
testinstallation.

Thank you.



-- 
May the source be with you