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 -
