Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Dave Page <dpage(at)postgresql(dot)org>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Hammond <andrew(dot)george(dot)hammond(at)gmail(dot)com>, CAJ CAJ <pguser(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-www <pgsql-www(at)postgresql(dot)org>
Subject: Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
Date: 2007-04-10 14:25:35
Message-ID: 20070410142535.GB7786@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-www

Dave Page escribió:
> 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.

Ah, but then it's not an decision to be made on arithmetics alone -- you
have to build a higher-level semantic comparison. Because if you want
to group by something else, for example the quality of Windows support,
you surely don't want 8.0 nor 8.1, because they have unfixable problems
(the pgstat bug, autovacuum not working). You need to include only 8.2
and higher.

> 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)?

It makes sense to store things separately when they have a semantic
difference. What we call "major" is the first two digits and dot. We
call "minor" to the third digit, and that's all. We don't have
"revisions". This is how it has ever been and we even document it as
such. Offering the first two digits separately would be a mistake
because it causes confusion over what's significant -- the first digit
by itself is not significant.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Wilkinson, Jim 2007-04-10 14:34:37 EXECUTE in a funtion to return a VIEW object ID
Previous Message Dave Page 2007-04-10 14:12:31 Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version

Browse pgsql-www by date

  From Date Subject
Next Message Tom Lane 2007-04-10 14:42:07 Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
Previous Message Dave Page 2007-04-10 14:12:31 Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version