support PostgreSQL 10 and above numbering scheme

[robe]

Looks like PGDG branched off 9.6 so master is now 10.0. Debbie's been testing master (so been testing 10.0) for past week which is why she's failing.

So this raises the issue that our code can't handle a version number of 10dev.

Error is:

make[1]: Entering directory '/var/lib/jenkins/workspace/postgis/branches/2.3/libpgcommon'
gcc -g -O2 -I../liblwgeom -I/var/lib/jenkins/workspace/pg/rel/pg9.6w64/include/postgresql/server   -fPIC -DPIC  -Wall -Wmissing-prototypes  -c -o gserialized_gist.o gserialized_gist.c
In file included from gserialized_gist.c:17:0:
../postgis_config.h:150:42: error: missing binary operator before token "10develPostgreSQL"
 #define POSTGIS_PGSQL_VERSION PostgreSQL 10develPostgreSQL 10devel
                                          ^
lwgeom_pg.h:142:5: note: in expansion of macro ‘POSTGIS_PGSQL_VERSION’
 #if POSTGIS_PGSQL_VERSION >= 85
     ^
Makefile:61: recipe for target 'gserialized_gist.o' failed
make[1]: *** [gserialized_gist.o] Error 1
make[1]: Leaving directory '/var/lib/jenkins/workspace/postgis/branches/2.3/libpgcommon'
GNUmakefile:16: recipe for target 'all' failed

I pushed this milestone to PostGIS 2.4, since we really don't need to support 10.0 in 2.3, unless we release 2.4 after 10.0 and even then we only need to support at 2.3.something (not 2.3.0)

[strk]

What does pg_config --version return, exactly ?

[robe]

PostgreSQL 10devel

[strk]

Uhm, so no minor version, basically

[robe]

Okay asked upstream on hackers if this is intentional and what we'll expect. Waiting for response.

[strk]

In 15048:

Accept dot-less output from pg_config --version

Hopefully fixes #3614

[robe]

strk see Tom's comment. He said we shouldn't even be using pg_config --version. Wasn't sure if we should change or good reason why we are not using what he proposes.

From ​https://www.postgresql.org/message-id/1585.1472410329%40sss.pgh.pa.us

"Regina Obe" <lr(at)pcorp(dot)us> writes:
> The routine in PostGIS to parse out the version number from pg_config is
> breaking in the 10 cycle

TBH, I wonder why you are doing that in the first place; it does not
seem like the most reliable source of version information.  If you
need to do compile-time tests, PG_CATALOG_VERSION is considered the
best thing to look at, or VERSION_NUM in Makefiles.

However, if you're dead set on getting a version number out of a string
representation, you'll need to make changes similar to commit
69dc5ae408f68c302029a6b43912a2cc16b1256c.

			regards, tom lane

[strk]

I wonder if the version code was available when we started :) I don't see the urge to change now, in any case

[robe]

Except for the fact that for 10+ we should not be using minor. We should be using major no? Then when 10.0 comes out we'd end up using minor again?

Anyway I'm not going to worry about this just yet. I haven't even looked at what the other items he mentioned return.

[strk]

We use a number, and behaviour switches based on being >= that number. It is not really important what that number represents, as long as it keeps growing between releases.

[robe]

I really think we need to rethink this. Especially now that minor will be going away.

[robe]

In 15397:

Revise the PGVERSION numbering scheme so also works for PostgreSQL 10beta1 and for all future PostgreSQL after 10
Note previous patch put in did not consider the case of when 10.11 comes, that would end up ranking higher than 11.0 (110 vs. 1011).
So we need to totally disregard the minor version for PostgreSQL >= 10
Closes #3614

[strk]

we need 2 digits for minor, so that 10dev becomes "1000" and 10.11 becomes "1011", no ?

[strk]

In 15629:

Rework PGSQL_VERSION again so to use 2-digits minor from 10 onward

See #3614

[strk]

In 15631:

Rework PGSQL_VERSION again so to use 2-digits minor from 10 onward

See #3614 (for 2.3 branch)

[robe]

Replying to strk:

we need 2 digits for minor, so that 10dev becomes "1000" and 10.11 becomes "1011", no ?

NO we don't. Please put it back.

They already said minor is the new micro for PostgreSQL 10 and above. So 10.11 is the same as 10.0. A postgis compiled for PostgreSQL 10 will work for PostgreSQL 10.11

We don't care about the minor.

[strk]

reverted in trunk with r15634 reverted in 2.3 branch with r15635 Sorry for the noise

[strk]

Do you have any other more "official" statement about the new PostgreSQL versioning scheme beside this commit ? ​https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=69dc5ae408f68c302029a6b43912a2cc16b1256c

[robe]

​https://www.postgresql.org/support/versioning/

[martinl]

I have still this issue on Debian Unstable:

pg_config --version 
PostgreSQL 10.3 (Debian 10.3-1)

make[1]: Entering directory '/var/local/src/postgis/libpgcommon'
gcc -I../liblwgeom -g -O2 -I/usr/include/postgresql/10/server   -fPIC -DPIC  -Wall -Wmissing-prototypes  -c -o gserialized_gist.o gserialized_gist.c
In file included from gserialized_gist.c:17:0:
../postgis_config.h:157:42: error: missing binary operator before token "10PostgreSQL"
 #define POSTGIS_PGSQL_VERSION PostgreSQL 10PostgreSQL 13
                                          ^
lwgeom_pg.h:131:5: note: in expansion of macro ‘POSTGIS_PGSQL_VERSION’
 #if POSTGIS_PGSQL_VERSION >= 85
     ^~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:61: gserialized_gist.o] Error 1
make[1]: Leaving directory '/var/local/src/postgis/libpgcommon'
make: *** [GNUmakefile:16: all] Error 1

[martinl]

Sorry for the noise, autogen.sh helped.