Add check for constant PGRES_TUPLES_CHUNK to fix compilation failures

[chschneider]

We have an OpenSUSE 15.6 installation with libpq5 installed (the current version being libpq5-17.2-..., i.e. compatible with postgresql17).
But as the current version of postgis does not work properly with postgresql17 so we are currently stuck with the packages postgresql16 and postgresql16-devel.

The file ext/pgsql/config.m4 only checks for the function PQsetChunkedRowsMode but the header files of postgresql16-devel does not define the constant PGRES_TUPLES_CHUNK in libpq-fe.h which leads to a compilation failure.

I added a check for PGRES_TUPLES_CHUNK to avoid this while keeping the feature enabled if the include file declares the constant.

[devnexen]

Seems correct thanks, I ll have a look soon-ish. Would you be able to target PHP-8.4 instead ?

[chschneider]

Seems correct thanks, I ll have a look soon-ish. Would you be able to target PHP-8.4 instead ?

I could do a PR for 8.4, is that preferred to master and then back-porting it? I was under the impression that PRs should be against master but that knowledge is probably outdated

[devnexen]

For fixes (inclucing build bugs), we target to the lowest branch the fix applies to. However if it is an issue for you to change target branch, I ll manage at commit time it s fairly small no worries :)

[devnexen]

Eventually it might be best to redo a proper PR for PHP-8.4 directly.

[chschneider]

Hmm, changing the target branch seemed to mess up the PR as hundred of changed files were shown. I think it is easier if I leave it at master, no?

Or I could delete the PR and create a new one for 8.4

[devnexen]

whatever suits you best, I ll review it in few dozen of minutes. Cheers.

[devnexen]

LGTM

[devnexen]

Thanks !

[petk]

Hello, this seems like something to improve in openSUSE, I believe. The libpq package should have a matching libpq-devel package instead of bundling the libpq-fe.h header file into the postgresql-devel package.

Opened here: https://bugzilla.opensuse.org/show_bug.cgi?id=1236400 to have this improved in the future versions.

Because what is happening now here is that libpq library file (/usr/lib64/libpq.so is built from the PostgreSQL 17 version) and the /usr/include/pgsql/libpq-fe.h header file belongs to different version. For example, postgresql16-devel will have libpq version 16 header. Which isn't ok and more bugs can happen that way.

[chschneider]

Hello, this seems like something to improve in openSUSE, I believe. The libpq package should have a matching libpq-devel package instead of bundling the libpq-fe.h header file into the postgresql-devel package.

I agree that there is a problem on the OpenSUSE side. Although I'm not 100% sure what the impact would be if PHP thinks it has support for all pg17 functionality while actually pg16 is installed and running. Would that cause problems or would that be gracefully handled by falling back on pg16 functions?

Anyway, thanks for opening a ticket upstream.

[petk]

Here, it's mostly a compilation issue when libpq is of version 17 and the header libpq-fe.h belongs to an earlier version without having some declarations: implicit declaration of function PQclosePrepared, PQchangePassword etc. It makes using header and library inconvenient and unreliable like this when developing. Symbols will be added when linking the libpq to php, so the end binary should be working ok, I guess. But it's a bad practice that can quickly turn into bugs. I wouldn't recommend building it like this.

Also, some build systems only check the libpq-fe.h file. If in some version, there will be some function removed, it might show up in the header, but won't be in the libpq.so library and similar issues.

[petk]

After further checking this, if I'm not mistaken, here only the correct postgresql devel package needs to be installed:

sudo zypper install postgresql17-devel libpq postgresql16-server

So, this will install libpq 17 version headers to /usr/include/pgsql and libpq.so.

While the running database server package is postgresql16-server and can be installed separately regardless of the belonging devel package. I think this should work ok. Yes?

[chschneider]

While the running database server package is postgresql16-server and can be installed separately regardless of the belonging devel package. I think this should work ok. Yes?

Unfortunately this does not work as we have to compile the postgis version ourselves which needs the correct postgresql16-server-devel which in turn conflicts with postgresql17-devel.