Thread: Access a newer Version of PGDB (v13) with an older libpq (v10 x86)
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 -
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 -
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 -
=?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
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 -
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
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