Re: 10.0 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 10.0
Date
Msg-id 4422.1465937807@sss.pgh.pa.us
Whole thread Raw
In response to Re: 10.0  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: 10.0  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@BlueTreble.com> writes:
> On 6/14/16 3:01 PM, Robert Haas wrote:
>> This seems kind of silly, because anybody who is writing code that
>> might have to run against an existing version of the database won't be
>> able to use it.  The one thing that absolutely has to be cross-version
>> is the method of determining which version you're running against.

> We're talking about a function that doesn't currently exist anyway.

Huh?  We're talking about PQserverVersion(), comparisons to PG_VERSION_NUM,
and related APIs.  Those most certainly exist now, and trying to supplant
them seems like a giant waste of time.

On the other hand, parsing fields out of version() mechanically has been
deprecated for as long as those other APIs have existed (which is since
8.0 or so).  version() is only meant for human consumption, so I see no
reason it shouldn't just start returning "10.0", "10.1", etc.  If that
breaks anyone's code, well, they should have switched to one of the
easier methods years ago.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Use of index for 50% column restriction
Next
From: Andreas Seltenreich
Date:
Subject: Should pg_export_snapshot() and currtid() be tagged parallel-unsafe?