| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Christoph Berg <christoph(dot)berg(at)credativ(dot)de> |
| Cc: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Package version in PG_VERSION and version() |
| Date: | 2018-01-17 15:03:08 |
| Message-ID: | 16522.1516201388@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Yeah, but the same argument could be made against the variant
> you're proposing. In theory, people could have written arbitrarily
> brittle checks of version numbers/strings. I'm not exactly convinced
> that it's your (or our) problem if they did.
BTW, as concrete evidence in this area, we could look to what happened
when we changed from three-part to two-part version numbers. Which
was pretty much nothing. I've been pleasantly surprised by how little
whining we've heard about that ;-). I think if downstream users have
been able to survive the change from "x.y.z" to "x.y", they can probably
manage "x.y (Debian something)". Maybe if you want to be careful, you
could make the addition only in PG 10 and up, guessing that anybody
who's really brittle in this area will be forced to improve their code
when they go to 10 anyway.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-01-17 15:07:37 | Re: master make check fails on Solaris 10 |
| Previous Message | Marina Polyakova | 2018-01-17 15:02:26 | Re: master make check fails on Solaris 10 |