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

From Dave Page
Subject Re: [pgsql-www] Re: programmatic way to fetch latest release for a given major.minor version
Date
Msg-id 461B9B4F.4070208@postgresql.org
Whole thread Raw
In response to Re: [pgsql-www] Re: programmatic way to fetch latest release for a given major.minor version  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [pgsql-www] Re: programmatic way to fetch latest release for a given major.minor version  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-general
Alvaro Herrera wrote:
> Dave Page escribió:
>> Magnus Hagander wrote:
>>> That is actually precisely my point. It makes *no sense* to filter based on
>>> 8.x. 8.0 is no more a major release than 7.4.
>> Yes it is - that's precisely why it was 8.0 and not 7.5.
>
> That was merely a marketing artifact; it was called 7.5 until the very
> end of the devel cycle.
>

Yes, but marketing is one reason why someone might want to group 8.x,
7.x etc on a website which is exactly the sort of thing this code is for.

As others have said, yes, you could do it but looking at a substring of
the version, and yes, you could do it with mathematical comparisons on
major.minor (with limitations - what happens if we get to 8.10 ?), but
would we suggest people use those techniques for searching their
databases for matching records, or would we suggest storing the
interesting elements in different columns for ease of use, flexibility
and efficiency? How does this differ (aside from the obvious)?

Regards, Dave

pgsql-general by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [pgsql-www] Re: programmatic way to fetch latest release for a given major.minor version
Next
From: Alvaro Herrera
Date:
Subject: Re: [pgsql-www] Re: programmatic way to fetch latest release for a given major.minor version