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
