Re: Backward compatibility

Hi, guys,
Below query does not even run:

SELECT version(), substring( version() from position( '\s' in version() ) );

Could you spot the error?

On Fri, Jul 21, 2017 at 12:11 PM, Igor Korot <ikorot01(at)gmail(dot)com> wrote:
> David et al,
>
> On Fri, Jul 21, 2017 at 12:00 PM, David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
>> On Fri, Jul 21, 2017 at 8:49 AM, Igor Korot <ikorot01(at)gmail(dot)com> wrote:
>>>
>>> MySQL uses this:
>>> https://dev.mysql.com/doc/refman/5.7/en/mysql-get-server-version.html.
>>> Is it safe to assume that PostgreSQL calculates the version the same way?
>>
>>
>> Yes and no. Things are changing with this next release. The next two major
>> releases will be:
>>
>> 10.x (or 10.0.x using historical nomenclature - 1000xx)
>> 11.x (or 11.0.x using historical nomenclature - 1100xx)
>>
>> For prior releases the major versions are:
>>
>> 9.2.x
>> 9.3.x
>> 9.4.x
>> 9.5.x
>> 9.6.x
>>
>> If you want to consider the 9 to be "major" and the .[2-6] to be minor for
>> mechanical purposes that's fine but the change from 9.5 to 9.6 is a major
>> change with backward incompatibilities - which a minor change doesn't allow.
>> In the new setup the thing you call "minor" will always remain at zero in
>> order to eventually mitigate the need to have this kind of discussion. Since
>> it is always going to be "0" we simply omit printing it.
>
> I just need to split the version by ".".
>
> But if the next releases will not increment second value and will
> number the releases
> as 10.0.0, 10.0.1, 10.0.2, then this schema won't work.
>
> Thank you.
>
>>
>> David J.