public inbox for [email protected]help / color / mirror / Atom feed
programmatic way to fetch latest release for a given major.minor version 30+ messages / 11 participants [nested] [flat]
* programmatic way to fetch latest release for a given major.minor version @ 2007-04-09 21:47 Andrew Hammond <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Andrew Hammond @ 2007-04-09 21:47 UTC (permalink / raw) To: [email protected] I'm writing a script that wants to know the latest release for a given major.minor version. Is there some better way than parsing http://www.postgresql.org/ftp/source/ or trying to connect to ftp (which is invariably timing out on me today. Is that box getting hammered or something?) and doing the parsing that? Both approaches feel quite awkward to me. Andrew ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-09 22:26 CAJ CAJ <[email protected]> parent: Andrew Hammond <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: CAJ CAJ @ 2007-04-09 22:26 UTC (permalink / raw) To: Andrew Hammond <[email protected]>; +Cc: [email protected] On 9 Apr 2007 14:47:20 -0700, Andrew Hammond < [email protected]> wrote: > > I'm writing a script that wants to know the latest release for a given > major.minor version. Is there some better way than parsing > http://www.postgresql.org/ftp/source/ or trying to connect to ftp > (which is invariably timing out on me today. Is that box getting > hammered or something?) and doing the parsing that? Both approaches > feel quite awkward to me. Use wget to download via HTTP (added recently). Probably wise to add a couple mirrors in your script. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-09 22:34 Andrew Hammond <[email protected]> parent: CAJ CAJ <[email protected]> 0 siblings, 3 replies; 30+ messages in thread From: Andrew Hammond @ 2007-04-09 22:34 UTC (permalink / raw) To: CAJ CAJ <[email protected]>; +Cc: [email protected] On 4/9/07, CAJ CAJ <[email protected]> wrote: > On 9 Apr 2007 14:47:20 -0700, Andrew Hammond > <[email protected]> wrote: > > I'm writing a script that wants to know the latest release for a given > > major.minor version. Is there some better way than parsing > > http://www.postgresql.org/ftp/source/ or trying to > connect to ftp > > (which is invariably timing out on me today. Is that box getting > > hammered or something?) and doing the parsing that? Both approaches > > feel quite awkward to me. > > Use wget to download via HTTP (added recently). Probably wise to add a > couple mirrors in your script. I'm not asking how to download stuff. I'm asking how to figure out the current release number for a given major.minor. I thought that was clear in my original post, but I guess not. For example, how do I determine (programmatically) the lastest version of 8.1. I'm also interested in a clever way to select one of the "close" mirrors at random for downloading via http. However I had planned to hold that question until I'd solved the first issue. Andrew ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-09 22:54 Alvaro Herrera <[email protected]> parent: Andrew Hammond <[email protected]> 2 siblings, 0 replies; 30+ messages in thread From: Alvaro Herrera @ 2007-04-09 22:54 UTC (permalink / raw) To: Andrew Hammond <[email protected]>; +Cc: CAJ CAJ <[email protected]>; [email protected] Andrew Hammond escribió: > On 4/9/07, CAJ CAJ <[email protected]> wrote: > >On 9 Apr 2007 14:47:20 -0700, Andrew Hammond > ><[email protected]> wrote: > >> I'm writing a script that wants to know the latest release for a given > >> major.minor version. Is there some better way than parsing > >> http://www.postgresql.org/ftp/source/ or trying to > >connect to ftp > >> (which is invariably timing out on me today. Is that box getting > >> hammered or something?) and doing the parsing that? Both approaches > >> feel quite awkward to me. > > > >Use wget to download via HTTP (added recently). Probably wise to add a > >couple mirrors in your script. > > I'm not asking how to download stuff. I'm asking how to figure out the > current release number for a given major.minor. I thought that was > clear in my original post, but I guess not. For example, how do I > determine (programmatically) the lastest version of 8.1. Maybe get configure.in from CVS: cvs log configure.in and parse the "symbolic names" list? -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-09 23:36 Listmail <[email protected]> parent: Andrew Hammond <[email protected]> 2 siblings, 0 replies; 30+ messages in thread From: Listmail @ 2007-04-09 23:36 UTC (permalink / raw) To: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; +Cc: [email protected] Here you go. Fetches versions and prints most recent minor for each major Tests all mirrors for speed and prints out the 4 fastest (takes some time) http://www.crummy.com/software/BeautifulSoup/ Have a nice day ! #! /bin/env python # -*- coding: utf-8 -*- import urllib, BeautifulSoup, re, time, sys def get_all_versions(): soup = BeautifulSoup.BeautifulSoup( urllib.urlopen( "http://ftp3.fr.postgresql.org/pub/postgresql/source/"; ).read() ) for a in soup( 'a', {'href': re.compile( r"v\d+.\d+.\d+" ) } ): yield map( int, re.search( r"v(\d+)\.(\d+)\.(\d+)*", a['href'] ).groups() ) def get_latest_versions(): lastversions = {} for a,b,c in sorted( get_all_versions() ): lastversions[ (a,b) ] = c return sorted( lastversions.items() ) def parse_query_string( url ): return dict( map( urllib.unquote_plus, pair.split('=',1) ) for pair in re.split( "&(?:amp;|)", urllib.splitquery( url )[1] ) ) def get_mirrors(): soup = BeautifulSoup.BeautifulSoup( urllib.urlopen( "http://wwwmaster.postgresql.org/download/mirrors-ftp"; ).read() ) for a in soup( 'a', {'href': re.compile( r"\?setmir=.*url=" ) } ): yield parse_query_string( a['href'] )['url'] def get_fastest_mirrors( urls, filename ): for url in urls: sys.stdout.write( " %s\r" % url ) t = time.time() try: urllib.urlopen( url + filename ) except: pass d = time.time()-t print "%.02f s" % d yield d, url for major, minor in get_latest_versions(): print "%d.%d.%d" % (major[0], major[1], minor) mirrors = get_mirrors() fastest = sorted( get_fastest_mirrors( mirrors, "sync_timestamp" ))[:4] for d, mirror in fastest: print "%.02f s %s" % (d,mirror) On Tue, 10 Apr 2007 00:34:02 +0200, Andrew Hammond <[email protected]> wrote: > On 4/9/07, CAJ CAJ <[email protected]> wrote: >> On 9 Apr 2007 14:47:20 -0700, Andrew Hammond >> <[email protected]> wrote: >> > I'm writing a script that wants to know the latest release for a given >> > major.minor version. Is there some better way than parsing >> > http://www.postgresql.org/ftp/source/ or trying to >> connect to ftp >> > (which is invariably timing out on me today. Is that box getting >> > hammered or something?) and doing the parsing that? Both approaches >> > feel quite awkward to me. >> >> Use wget to download via HTTP (added recently). Probably wise to add a >> couple mirrors in your script. > > I'm not asking how to download stuff. I'm asking how to figure out the > current release number for a given major.minor. I thought that was > clear in my original post, but I guess not. For example, how do I > determine (programmatically) the lastest version of 8.1. > > I'm also interested in a clever way to select one of the "close" > mirrors at random for downloading via http. However I had planned to > hold that question until I'd solved the first issue. > > Andrew > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 07:36 Dave Page <[email protected]> parent: Andrew Hammond <[email protected]> 2 siblings, 1 reply; 30+ messages in thread From: Dave Page @ 2007-04-10 07:36 UTC (permalink / raw) To: Andrew Hammond <[email protected]>; +Cc: CAJ CAJ <[email protected]>; [email protected] Andrew Hammond wrote: > On 4/9/07, CAJ CAJ <[email protected]> wrote: >> On 9 Apr 2007 14:47:20 -0700, Andrew Hammond >> <[email protected]> wrote: >> > I'm writing a script that wants to know the latest release for a given >> > major.minor version. Is there some better way than parsing >> > http://www.postgresql.org/ftp/source/ or trying to >> connect to ftp >> > (which is invariably timing out on me today. Is that box getting >> > hammered or something?) and doing the parsing that? Both approaches >> > feel quite awkward to me. >> >> Use wget to download via HTTP (added recently). Probably wise to add a >> couple mirrors in your script. > > I'm not asking how to download stuff. I'm asking how to figure out the > current release number for a given major.minor. I thought that was > clear in my original post, but I guess not. For example, how do I > determine (programmatically) the lastest version of 8.1. Currently you can't without parsing pages. > I'm also interested in a clever way to select one of the "close" > mirrors at random for downloading via http. However I had planned to > hold that question until I'd solved the first issue. You might find this of use: http://www.postgresql.org/mirrors.xml. It's updated regularly, so the mirrors should all have test OK within the last 48 hours. Regards, Dave. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 08:15 Magnus Hagander <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 08:15 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 08:36:10AM +0100, Dave Page wrote: > Andrew Hammond wrote: > > On 4/9/07, CAJ CAJ <[email protected]> wrote: > >> On 9 Apr 2007 14:47:20 -0700, Andrew Hammond > >> <[email protected]> wrote: > >> > I'm writing a script that wants to know the latest release for a given > >> > major.minor version. Is there some better way than parsing > >> > http://www.postgresql.org/ftp/source/ or trying to > >> connect to ftp > >> > (which is invariably timing out on me today. Is that box getting > >> > hammered or something?) and doing the parsing that? Both approaches > >> > feel quite awkward to me. > >> > >> Use wget to download via HTTP (added recently). Probably wise to add a > >> couple mirrors in your script. > > > > I'm not asking how to download stuff. I'm asking how to figure out the > > current release number for a given major.minor. I thought that was > > clear in my original post, but I guess not. For example, how do I > > determine (programmatically) the lastest version of 8.1. > > Currently you can't without parsing pages. I've been meaning to do this for a while now, and I guess this might be a good motivator ;-) The idea would, of course, be to build this from a set of common data with the frontpage of the website, so they're always in sync. As I see it, there are basically three ways of doing it: 1) Fold it into mirrors.xml. That's going to be a bit hard given how the schema is (since the root element is mirror), but it would work. Another downside is that is that people who just want to check the latest version will have to pull down the whole mirror list file. This file is also rewritten often, so checks on If-Modified-Since will fail. 2) Create a new file with a specific schema. Something like: <version> <version major="8.2" minor="8.2.3" /> <version major="8.1" minor="8.1.8" /> </version> This is the most lightweight solution. 3) Use RSS format. Not exactly sure how it would look, but it can certainly be done in RSS... I think I prefer option 2, but what do others think? //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 08:52 Dave Page <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 2 replies; 30+ messages in thread From: Dave Page @ 2007-04-10 08:52 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www Magnus Hagander wrote: > 2) Create a new file with a specific schema. Something like: > <version> > <version major="8.2" minor="8.2.3" /> > <version major="8.1" minor="8.1.8" /> > </version> > This is the most lightweight solution. More like: <versions> <version major="8" minor="2" revision="3" /> <version major="8" minor="1" revision="8" /> </versions> But I can't help thinking that we should have some additional values for release notes, download sub-URLs (to be appended to the mirror roots) etc. Regards, Dave. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 09:09 Listmail <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 1 reply; 30+ messages in thread From: Listmail @ 2007-04-10 09:09 UTC (permalink / raw) To: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www I love Open Source XD http://ethan.tira-thompson.com/cvslog2web/ Note that this is overkill (but it would look SEXY on the site). However, the original poster probably wants to know when to update his servers, so he won't care about CVS commits... If there was a RSS feed of new postgres versions I'd subscribe to it though. > <versions> > <version major="8" minor="2" revision="3" /> > <version major="8" minor="1" revision="8" /> > </versions> > > But I can't help thinking that we should have some additional values for > release notes, download sub-URLs (to be appended to the mirror roots) > etc. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 10:18 Magnus Hagander <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 3 replies; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 10:18 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 09:52:52AM +0100, Dave Page wrote: > Magnus Hagander wrote: > > 2) Create a new file with a specific schema. Something like: > > <version> > > <version major="8.2" minor="8.2.3" /> > > <version major="8.1" minor="8.1.8" /> > > </version> > > This is the most lightweight solution. > > More like: > > <versions> > <version major="8" minor="2" revision="3" /> > <version major="8" minor="1" revision="8" /> > </versions> But that doesn't reflect our terminology. Per our own terminology, bioth 8.1 and 8.2 are major versions. Not only is that what we've been saying for years, we even documented it at http://www.postgresql.org/support/versioning. > But I can't help thinking that we should have some additional values for > release notes, download sub-URLs (to be appended to the mirror roots) etc. Yeah, thus the X in XML :-) But given that we might want to add things like this, having our own custom XML format certainly makes a bit more sense, it might be harder to try to trick it into RSS. //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 10:20 Magnus Hagander <[email protected]> parent: Listmail <[email protected]> 0 siblings, 0 replies; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 10:20 UTC (permalink / raw) To: Listmail <[email protected]>; +Cc: Dave Page <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 11:09:50AM +0200, Listmail wrote: > > I love Open Source XD > > http://ethan.tira-thompson.com/cvslog2web/ Hmm. Don't tell people about my secret plans :) (Though I hadn't looked at that piece of software in particylar) > Note that this is overkill (but it would look SEXY on the site). > However, the original poster probably wants to know when to update > his servers, so he won't care about CVS commits... > If there was a RSS feed of new postgres versions I'd subscribe to it > though. That's the argument for RSS - you acn subscribe to it from standard RSS readers. Perhaps we need to do both... //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 11:03 Dave Page <[email protected]> parent: Magnus Hagander <[email protected]> 2 siblings, 1 reply; 30+ messages in thread From: Dave Page @ 2007-04-10 11:03 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www Magnus Hagander wrote: > On Tue, Apr 10, 2007 at 09:52:52AM +0100, Dave Page wrote: >> Magnus Hagander wrote: >>> 2) Create a new file with a specific schema. Something like: >>> <version> >>> <version major="8.2" minor="8.2.3" /> >>> <version major="8.1" minor="8.1.8" /> >>> </version> >>> This is the most lightweight solution. >> More like: >> >> <versions> >> <version major="8" minor="2" revision="3" /> >> <version major="8" minor="1" revision="8" /> >> </versions> > > But that doesn't reflect our terminology. Per our own terminology, bioth > 8.1 and 8.2 are major versions. Not only is that what we've been saying for > years, we even documented it at > http://www.postgresql.org/support/versioning. Yeah yeah, but terminology aside, having 2 or three digits in each attribute is just wrong! >> But I can't help thinking that we should have some additional values for >> release notes, download sub-URLs (to be appended to the mirror roots) etc. > > Yeah, thus the X in XML :-) :-p > But given that we might want to add things like this, having our own custom > XML format certainly makes a bit more sense, it might be harder to try to > trick it into RSS. Agreed. /D ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 11:15 Magnus Hagander <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 2 replies; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 11:15 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 12:03:44PM +0100, Dave Page wrote: > Magnus Hagander wrote: > > On Tue, Apr 10, 2007 at 09:52:52AM +0100, Dave Page wrote: > >> Magnus Hagander wrote: > >>> 2) Create a new file with a specific schema. Something like: > >>> <version> > >>> <version major="8.2" minor="8.2.3" /> > >>> <version major="8.1" minor="8.1.8" /> > >>> </version> > >>> This is the most lightweight solution. > >> More like: > >> > >> <versions> > >> <version major="8" minor="2" revision="3" /> > >> <version major="8" minor="1" revision="8" /> > >> </versions> > > > > But that doesn't reflect our terminology. Per our own terminology, bioth > > 8.1 and 8.2 are major versions. Not only is that what we've been saying for > > years, we even documented it at > > http://www.postgresql.org/support/versioning. > > Yeah yeah, but terminology aside, having 2 or three digits in each > attribute is just wrong! 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? //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 11:35 Dave Page <[email protected]> parent: Magnus Hagander <[email protected]> 1 sibling, 2 replies; 30+ messages in thread From: Dave Page @ 2007-04-10 11:35 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www 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. Regards,D ave. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 11:44 Listmail <[email protected]> parent: Magnus Hagander <[email protected]> 1 sibling, 1 reply; 30+ messages in thread From: Listmail @ 2007-04-10 11:44 UTC (permalink / raw) To: [email protected] >> Yeah yeah, but terminology aside, having 2 or three digits in each >> attribute is just wrong! > > 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? > > //Magnus Just pretend that : - version = a tuple of integers (a, b, c, ...) - major = (a, b) - minor = (c, ...) Besides, that is sortable (unlike strings where 15 < 2) : latest minor for major : major, max(minor) where major = what you want <pgversion><major><int value="8" /><int value="2" /></major><minor><int value="3" /></minor></pgversion> from BeautifulSoup import BeautifulSoup as Soup s = Soup("""<pgversion><major><int value="8" /><int value="2" /></major><minor><int value="3" /></minor></pgversion>""" ) >>> v = s.find('pgversion') >>> [int(x['value']) for x in v.find('major') ] [8, 2] >>> [int(x['value']) for x in v.find('minor') ] [3] ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 12:27 Magnus Hagander <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 1 reply; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 12:27 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; 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 ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 12:44 Martijn van Oosterhout <[email protected]> parent: Magnus Hagander <[email protected]> 2 siblings, 1 reply; 30+ messages in thread From: Martijn van Oosterhout @ 2007-04-10 12:44 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Dave Page <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 12:18:52PM +0200, Magnus Hagander wrote: > But given that we might want to add things like this, having our own custom > XML format certainly makes a bit more sense, it might be harder to try to > trick it into RSS. I'd say do it in the format you're most comfortable with. Then some XSLT wizard can convert it into RSS from there... Have a nice day, -- Martijn van Oosterhout <[email protected]> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to litigate. Attachments: [application/pgp-signature] signature.asc (189B, 2-signature.asc) download ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 12:54 Magnus Hagander <[email protected]> parent: Martijn van Oosterhout <[email protected]> 0 siblings, 0 replies; 30+ messages in thread From: Magnus Hagander @ 2007-04-10 12:54 UTC (permalink / raw) To: Dave Page <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 02:44:42PM +0200, Martijn van Oosterhout wrote: > On Tue, Apr 10, 2007 at 12:18:52PM +0200, Magnus Hagander wrote: > > But given that we might want to add things like this, having our own custom > > XML format certainly makes a bit more sense, it might be harder to try to > > trick it into RSS. > > I'd say do it in the format you're most comfortable with. Then some > XSLT wizard can convert it into RSS from there... Too late, I already did the RSS. Which was very simple, because of the RSS framework stuff already in place on the website. *However*, that one doesn't contain all the information that a program would want, and certainly not in an easily parseable format for them. It's designed for people in the other end. So I intend to do a "proper XML format" as well. //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 12:59 Peter Eisentraut <[email protected]> parent: Dave Page <[email protected]> 1 sibling, 0 replies; 30+ messages in thread From: Peter Eisentraut @ 2007-04-10 12:59 UTC (permalink / raw) To: pgsql-www; +Cc: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected] Am Dienstag, 10. April 2007 13:35 schrieb Dave Page: > 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 use case is just as valid as wanting to show only releases >= 7.4. The user could run an arithmetic expression to check for that and >= 8.0. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 13:13 Dave Page <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Dave Page @ 2007-04-10 13:13 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www 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. /D ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 13:57 Alvaro Herrera <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Alvaro Herrera @ 2007-04-10 13:57 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www 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. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 14:12 Dave Page <[email protected]> parent: Alvaro Herrera <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Dave Page @ 2007-04-10 14:12 UTC (permalink / raw) To: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www 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 ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 14:25 Alvaro Herrera <[email protected]> parent: Dave Page <[email protected]> 0 siblings, 2 replies; 30+ messages in thread From: Alvaro Herrera @ 2007-04-10 14:25 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; 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 ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 14:42 Tom Lane <[email protected]> parent: Alvaro Herrera <[email protected]> 1 sibling, 0 replies; 30+ messages in thread From: Tom Lane @ 2007-04-10 14:42 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www Alvaro Herrera <[email protected]> writes: > 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. While I agree with this position, ISTM that an easy compromise is available: put both formats into the data. regards, tom lane ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 14:58 Dave Page <[email protected]> parent: Alvaro Herrera <[email protected]> 1 sibling, 0 replies; 30+ messages in thread From: Dave Page @ 2007-04-10 14:58 UTC (permalink / raw) To: Dave Page <[email protected]>; Magnus Hagander <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www Alvaro Herrera wrote: > 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. Yes, and for the most part it's true (certainly as far as the purpose of that documentation is concerned), however it all falls apart next time we have the 'are there enough new features in this release to bump the first digit' discussion which, along with the fact that we have bumped it twice now, is proof in itself that we do give it some meaning. Anyhoo, I've said my piece now - I'll await the inevitable replies telling me I'm a donut and then move on :-) Regards, Dave ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 16:48 Jorge Godoy <[email protected]> parent: Listmail <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Jorge Godoy @ 2007-04-10 16:48 UTC (permalink / raw) To: Listmail <[email protected]>; +Cc: [email protected] Listmail <[email protected]> writes: >>> Yeah yeah, but terminology aside, having 2 or three digits in each >>> attribute is just wrong! >> >> 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? >> >> //Magnus > > Just pretend that : > > - version = a tuple of integers (a, b, c, ...) > - major = (a, b) > - minor = (c, ...) > > Besides, that is sortable (unlike strings where 15 < 2) : But then, floats are as sortable as integers and 8.3 < 15.1... -- Jorge Godoy <[email protected]> ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: programmatic way to fetch latest release for a given major.minor version @ 2007-04-10 17:00 Peter Wilson <[email protected]> parent: Jorge Godoy <[email protected]> 0 siblings, 0 replies; 30+ messages in thread From: Peter Wilson @ 2007-04-10 17:00 UTC (permalink / raw) To: [email protected] Jorge Godoy wrote: > Listmail <[email protected]> writes: > >>>> Yeah yeah, but terminology aside, having 2 or three digits in each >>>> attribute is just wrong! >>> 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? >>> >>> //Magnus >> Just pretend that : >> >> - version = a tuple of integers (a, b, c, ...) >> - major = (a, b) >> - minor = (c, ...) >> >> Besides, that is sortable (unlike strings where 15 < 2) : > > But then, floats are as sortable as integers and 8.3 < 15.1... > > 8.7, 8.9, 8.10 - oops. 8.10 < 8.9 The 'period' is effectively a field separator, with the unfortunate side-effect that it looks like a number. Unless of course, the version after 8.9 *will* be 9.0, in which case it is a number and you're right. Pete ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-11 16:20 Magnus Hagander <[email protected]> parent: Magnus Hagander <[email protected]> 2 siblings, 1 reply; 30+ messages in thread From: Magnus Hagander @ 2007-04-11 16:20 UTC (permalink / raw) To: Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Tue, Apr 10, 2007 at 12:18:52PM +0200, Magnus Hagander wrote: > On Tue, Apr 10, 2007 at 09:52:52AM +0100, Dave Page wrote: > > Magnus Hagander wrote: > > > 2) Create a new file with a specific schema. Something like: > > > <version> > > > <version major="8.2" minor="8.2.3" /> > > > <version major="8.1" minor="8.1.8" /> > > > </version> > > > This is the most lightweight solution. > > > > More like: > > > > <versions> > > <version major="8" minor="2" revision="3" /> > > <version major="8" minor="1" revision="8" /> > > </versions> > Ok, I've added one of these as well now, alongside the RSS feed. You can get the pg specific XML file at: http://www.postgresql.org/versions.xml If someone wants the schema change, react *now*. Later on we can only append to it, and not change it :) //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-11 16:49 Listmail <[email protected]> parent: Magnus Hagander <[email protected]> 0 siblings, 1 reply; 30+ messages in thread From: Listmail @ 2007-04-11 16:49 UTC (permalink / raw) To: Magnus Hagander <[email protected]>; Dave Page <[email protected]>; +Cc: Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www > If someone wants the schema change, react *now*. Later on we can only > append to it, and not change it :) Since I like to complain... <numericversion v1="8" v2="2" v3="3"/> Suppose you someday add another dot, or a "b" for beta, wouldn't it be better to have <versionlist><item>8</item><item>2</item><item>3</item></versionlist> ... or <item value="3" /> ^ permalink raw reply [nested|flat] 30+ messages in thread
* Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version @ 2007-04-11 18:07 Magnus Hagander <[email protected]> parent: Listmail <[email protected]> 0 siblings, 0 replies; 30+ messages in thread From: Magnus Hagander @ 2007-04-11 18:07 UTC (permalink / raw) To: Listmail <[email protected]>; +Cc: Dave Page <[email protected]>; Andrew Hammond <[email protected]>; CAJ CAJ <[email protected]>; [email protected]; pgsql-www On Wed, Apr 11, 2007 at 06:49:18PM +0200, Listmail wrote: > > > >If someone wants the schema change, react *now*. Later on we can only > >append to it, and not change it :) > > Since I like to complain... > > <numericversion v1="8" v2="2" v3="3"/> > > Suppose you someday add another dot, or a "b" for beta, wouldn't it > be better to have > > <versionlist><item>8</item><item>2</item><item>3</item></versionlist> IIRC, but not entirely sure, the order of items in XML is not guaranteed. So you'd need something like <versionlist><item seq="1">8</item><item seq="2">2</item> etc etc I'm not sure, but I have some kind of memory of that ;-) As for beta, we're only going to be listing production versions in this one. It's there to list the latest available version in each released series. And if we add another dot, we can just add a v4="7" attribute. Adding is not a problem, only modifying. //Magnus ^ permalink raw reply [nested|flat] 30+ messages in thread
end of thread, other threads:[~2007-04-11 18:07 UTC | newest] Thread overview: 30+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2007-04-09 21:47 programmatic way to fetch latest release for a given major.minor version Andrew Hammond <[email protected]> 2007-04-09 22:26 ` CAJ CAJ <[email protected]> 2007-04-09 22:34 ` Andrew Hammond <[email protected]> 2007-04-09 22:54 ` Alvaro Herrera <[email protected]> 2007-04-09 23:36 ` Listmail <[email protected]> 2007-04-10 07:36 ` Dave Page <[email protected]> 2007-04-10 08:15 ` Magnus Hagander <[email protected]> 2007-04-10 08:52 ` Dave Page <[email protected]> 2007-04-10 09:09 ` Listmail <[email protected]> 2007-04-10 10:20 ` Magnus Hagander <[email protected]> 2007-04-10 10:18 ` Magnus Hagander <[email protected]> 2007-04-10 11:03 ` Dave Page <[email protected]> 2007-04-10 11:15 ` Magnus Hagander <[email protected]> 2007-04-10 11:35 ` Dave Page <[email protected]> 2007-04-10 12:27 ` Magnus Hagander <[email protected]> 2007-04-10 13:13 ` Dave Page <[email protected]> 2007-04-10 13:57 ` Alvaro Herrera <[email protected]> 2007-04-10 14:12 ` Dave Page <[email protected]> 2007-04-10 14:25 ` Alvaro Herrera <[email protected]> 2007-04-10 14:42 ` Tom Lane <[email protected]> 2007-04-10 14:58 ` Dave Page <[email protected]> 2007-04-10 12:59 ` Peter Eisentraut <[email protected]> 2007-04-10 11:44 ` Listmail <[email protected]> 2007-04-10 16:48 ` Jorge Godoy <[email protected]> 2007-04-10 17:00 ` Peter Wilson <[email protected]> 2007-04-10 12:44 ` Martijn van Oosterhout <[email protected]> 2007-04-10 12:54 ` Magnus Hagander <[email protected]> 2007-04-11 16:20 ` Magnus Hagander <[email protected]> 2007-04-11 16:49 ` Listmail <[email protected]> 2007-04-11 18:07 ` Magnus Hagander <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox