public inbox for [email protected]  

help / color / mirror / Atom feed

From: Alvaro Herrera <[email protected]>
To: Dave Page <[email protected]>
Cc: Magnus Hagander <[email protected]>
Cc: Andrew Hammond <[email protected]>
Cc: CAJ CAJ <[email protected]>
Cc: [email protected]
Cc: pgsql-www <[email protected]>
Subject: Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
Date: Tue, 10 Apr 2007 10:25:35 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

view thread (30+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox