PostgreSQL Version 10, missing minor version

Started by Regina Obeover 9 years ago6 messages

Regina Obe

lr@pcorp.us

over 9 years ago

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Joe Conway

mail@joeconway.com

over 9 years ago

In reply to: Regina Obe (#1)

Re: PostgreSQL Version 10, missing minor version

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

Tom Lane

tgl@sss.pgh.pa.us

over 9 years ago

In reply to: Regina Obe (#1)

Re: PostgreSQL Version 10, missing minor version

"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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Craig Ringer

craig@2ndquadrant.com

over 9 years ago

In reply to: Tom Lane (#3)

1 attachment(s)

Re: PostgreSQL Version 10, missing minor version

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

Attachments:

0001-Report-server_version_num-alongside-server_version-i.patchtext/x-patch; charset=US-ASCII; name=0001-Report-server_version_num-alongside-server_version-i.patchDownload

From 9e6fce06b07ca8e272a6125c9a75ac2ba7714d03 Mon Sep 17 00:00:00 2001
From: Craig Ringer <craig@2ndquadrant.com>
Date: Mon, 29 Aug 2016 11:31:52 +0800
Subject: [PATCH] Report server_version_num alongside server_version in startup
 packet

We expose PG_VERSION_NUM in Makefiles and headers and in pg_settings,
but the equivalent server_version_num isn't sent in the startup packet
so clients must rely on parsing the server_version. Make
server_version_num GUC_REPORT so clients can use server_version_num if
present and fall back to server_version for older PostgreSQL versions.
---
 src/backend/utils/misc/guc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index c5178f7..36e3604 100644
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -2767,7 +2767,7 @@ static struct config_int ConfigureNamesInt[] =
 		{"server_version_num", PGC_INTERNAL, PRESET_OPTIONS,
 			gettext_noop("Shows the server version as an integer."),
 			NULL,
-			GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+			GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE | GUC_REPORT
 		},
 		&server_version_num,
 		PG_VERSION_NUM, PG_VERSION_NUM, PG_VERSION_NUM,
-- 
2.5.5

Andres Freund

andres@anarazel.de

over 9 years ago

In reply to: Craig Ringer (#4)

Re: PostgreSQL Version 10, missing minor version

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Craig Ringer

craig@2ndquadrant.com

over 9 years ago

In reply to: Andres Freund (#5)

Re: PostgreSQL Version 10, missing minor version

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers