Re: programmatic way to fetch latest release for a given major.minor version - Mailing list pgsql-general

From Peter Wilson
Subject Re: programmatic way to fetch latest release for a given major.minor version
Date
Msg-id evgfs3$2pm7$1@news.hub.org
Whole thread Raw
In response to Re: programmatic way to fetch latest release for a given major.minor version  (Jorge Godoy <jgodoy@gmail.com>)
List pgsql-general
Jorge Godoy wrote:
> Listmail <lists@peufeu.com> writes:
>
>>>> Yeah yeah, but terminology aside, having 2 or three digits in each
>>>> attribute is just wrong!
>>> Terminology aside, why? The unit is "8.1" not "8" and "1". It makes no
>>> sense to say you're on version 8, in the given context, so why should the
>>> XML data pretend there is?
>>>
>>> //Magnus
>>     Just pretend that :
>>
>>     - version = a tuple of integers (a, b, c, ...)
>>     - major = (a, b)
>>     - minor = (c, ...)
>>
>>     Besides, that is sortable (unlike strings where 15 < 2) :
>
> But then, floats are as sortable as integers and 8.3 < 15.1...
>
>

8.7, 8.9, 8.10 - oops. 8.10 < 8.9

The 'period' is effectively a field separator, with the unfortunate side-effect
that it looks like a number.

Unless of course, the version after 8.9 *will* be 9.0, in which case it is a
number and you're right.

Pete

pgsql-general by date:

Previous
From: Jorge Godoy
Date:
Subject: Re: programmatic way to fetch latest release for a given major.minor version
Next
From: William Garrison
Date:
Subject: Do I need serializable for this query?