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

From Magnus Hagander
Subject Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
Date
Msg-id 20070410122708.GB25739@svr2.hagander.net
Whole thread Raw
In response to Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version  (Dave Page <dpage@postgresql.org>)
Responses Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version  (Dave Page <dpage@postgresql.org>)
List pgsql-www
On Tue, Apr 10, 2007 at 12:35:38PM +0100, Dave Page wrote:
> Magnus Hagander wrote:
> > 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?
>
> Because serving the data in the decomposed format gives the consumer the
> maximum flexibility to do as they wish with the data. I find it hard to
> see why, as a relational database guy, you'd want to offer the data as
> "8.1", "8.1.3" etc. when you can just give the three parts separately
> and allow people to check whatever they need without having to chop up
> strings!
>
> Imagine wanting to display only the details of the 8.x releases on a
> site for example. In your schema, you'd have to use a substring match on
> an attribute value to filter out 6.x and 7.x.

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. And we'd encourage people to
do that.

//Magnus

pgsql-www by date:

Previous
From: Dave Page
Date:
Subject: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version
Next
From: Magnus Hagander
Date:
Subject: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version