Thread: PostgreSQL Version 10, missing minor version
The routine in PostGIS to parse out the version number from pg_config is breaking in the 10 cycle. Issue seems to be because there is no minor specified. e.g. pgconfig --version returns: PostgreSQL 10devel Instead of expected PostgreSQL 10.0devel Is this the way it's going to be or will there be a .0 tacked at the end before release? Thanks, Regina
On 08/28/2016 09:55 AM, Regina Obe wrote: > The routine in PostGIS to parse out the version number from pg_config is > breaking in the 10 cycle. > > Issue seems to be because there is no minor specified. > > e.g. > > pgconfig --version > > returns: > > PostgreSQL 10devel > > Instead of expected > > PostgreSQL 10.0devel > > Is this the way it's going to be or will there be a .0 tacked at the end > before release? Given the version numbering change, postgres version 10 is equivalent to version 9.6 (i.e. the "major" version number), and 10.0 is equivalent to 9.6.0 (i.e. the "major.minor" version). So I suspect that given... pg_config --version PostgreSQL 9.5.3 pg_config --version PostgreSQL 9.6beta4 ... you will see Postgres 10 go through the stages... pg_config --version PostgreSQL 10devel pg_config --version PostgreSQL 10beta1 pg_config --version PostgreSQL 10.0 HTH, Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
"Regina Obe" <lr@pcorp.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
On 29 August 2016 at 02:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Regina Obe" <lr@pcorp.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. This is my cue to pop up and say that if you're looking at the startup message you have to use the version string, despite it not being the most reliable source of information, because we don't send server_version_num ;) Patch attached. Yes, I know PostGIS doesn't use it, but it makes no sense to tell people not to parse the server version out in some situations then force them to in others. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Attachment
On 2016-08-29 11:41:00 +0800, Craig Ringer wrote: > On 29 August 2016 at 02:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > "Regina Obe" <lr@pcorp.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. > > This is my cue to pop up and say that if you're looking at the startup > message you have to use the version string, despite it not being the > most reliable source of information, because we don't send > server_version_num ;) > > Patch attached. Yes, I know PostGIS doesn't use it, but it makes no > sense to tell people not to parse the server version out in some > situations then force them to in others. If they're using pg_config atm, that seems unlikely to be related. That sounds more like a build time issue - there won't be a running server.
On 29 August 2016 at 11:46, Andres Freund <andres@anarazel.de> wrote: > On 2016-08-29 11:41:00 +0800, Craig Ringer wrote: >> On 29 August 2016 at 02:52, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> > "Regina Obe" <lr@pcorp.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. >> >> This is my cue to pop up and say that if you're looking at the startup >> message you have to use the version string, despite it not being the >> most reliable source of information, because we don't send >> server_version_num ;) >> >> Patch attached. Yes, I know PostGIS doesn't use it, but it makes no >> sense to tell people not to parse the server version out in some >> situations then force them to in others. > > If they're using pg_config atm, that seems unlikely to be related. That > sounds more like a build time issue - there won't be a running server. Yeah, you're right, and I shouldn't hijack an unrelated thread. Please disregard, will follow up separately. -- Craig Ringer http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services