From: | Peter Wilson <petew(at)yellowhawk(dot)co(dot)uk> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: programmatic way to fetch latest release for a given major.minor version |
Date: | 2007-04-10 17:00:59 |
Message-ID: | evgfs3$2pm7$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-www |
Jorge Godoy wrote:
> Listmail <lists(at)peufeu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | William Garrison | 2007-04-10 18:44:28 | Do I need serializable for this query? |
Previous Message | Jorge Godoy | 2007-04-10 16:48:08 | Re: programmatic way to fetch latest release for a given major.minor version |
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Lelarge | 2007-04-10 21:58:39 | Website's french translation |
Previous Message | Jorge Godoy | 2007-04-10 16:48:08 | Re: programmatic way to fetch latest release for a given major.minor version |