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@xxxxxxxxx> wrote: > David et al, > > On Fri, Jul 21, 2017 at 12:00 PM, David G. Johnston > <david.g.johnston@xxxxxxxxx> wrote: >> On Fri, Jul 21, 2017 at 8:49 AM, Igor Korot <ikorot01@xxxxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
