Re: New version numbering practices - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us>:

 

0) server_version needs a dance to parse.

For instance, recent "Stamp version 10devel" patch did touch "server_version" parsing in fe-exec.c: https://github.com/vlsi/postgres/pull/2/files#diff-2df5cad06efe4485ad362b0eb765cec0L986

Of course it might happen there was just a bug in fe-exec.c, however that is a smell. Lots of clients might need to update server_version parsing logic for no reason except "support 10devel kind of versions".

There are cases when the dance is locale-specific: https://github.com/pgjdbc/pgjdbc/pull/190

1) By saying "just parse server_version" you are basically forcing every postgresql client (except libpq) to implement, test, and support its own parse logic. Do you care of having robust clients that will not break in parts when tested against 10.whatever?

1) Several examples were provided by Craig: https://www.postgresql.org/message-id/CAMsr%2BYFt1NcjseExt_Ov%2Bfrk0Jzb0-DKqYKt8ALzVEXHBM0jKg%40mail.gmail.com

Craig> This means that at least when connecting to newer servers clients no longer have to do any stupid dances around parsing "9.5beta1", "9.4.0mycustompatchedPg"

2) Official documentation suggests "see also server_version_num for a machine-readable version."

Even though "one can simply try to parse server_version value", I claim that server_version_num is much more machine-readable than server_version one.