Re: [HACKERS] PostgreSQL Version 10, missing minor version

[Craig Ringer]

On 29 August 2016 at 11:46, Andres Freund  wrote:
> On 2016-08-29 11:41:00 +0800, Craig Ringer wrote:
>> On 29 August 2016 at 02:52, Tom Lane  wrote:
>> > "Regina Obe"  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

Re: [HACKERS] PostgreSQL Version 10, missing minor version

[Andres Freund]

On 2016-08-29 11:41:00 +0800, Craig Ringer wrote:
> On 29 August 2016 at 02:52, Tom Lane  wrote:
> > "Regina Obe"  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

Re: [HACKERS] PostgreSQL Version 10, missing minor version

[Craig Ringer]

On 29 August 2016 at 02:52, Tom Lane  wrote:
> "Regina Obe"  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
From 9e6fce06b07ca8e272a6125c9a75ac2ba7714d03 Mon Sep 17 00:00:00 2001
From: Craig Ringer 
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
 		},
 		_version_num,
 		PG_VERSION_NUM, PG_VERSION_NUM, PG_VERSION_NUM,
-- 
2.5.5


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

Re: [HACKERS] PostgreSQL Version 10, missing minor version

[Tom Lane]

"Regina Obe"  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

Re: [HACKERS] PostgreSQL Version 10, missing minor version

[Joe Conway]

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



signature.asc
Description: OpenPGP digital signature

[HACKERS] PostgreSQL Version 10, missing minor version

[Regina Obe]

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