Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 3C20D9FB859; Tue, 10 Apr 2007 11:45:08 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 25122-04-7; Tue, 10 Apr 2007 11:45:03 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 9F4BD9FB719; Tue, 10 Apr 2007 11:42:12 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l3AEg88f025897; Tue, 10 Apr 2007 10:42:08 -0400 (EDT) To: Alvaro Herrera cc: Dave Page , Magnus Hagander , Andrew Hammond , CAJ CAJ , pgsql-general@postgresql.org, pgsql-www Subject: Re: Re: [GENERAL] programmatic way to fetch latest release for a given major.minor version In-reply-to: <20070410142535.GB7786@alvh.no-ip.org> References: <20070410081558.GB24976@svr2.hagander.net> <461B5064.8010004@postgresql.org> <20070410101852.GC24976@svr2.hagander.net> <461B6F10.3040800@postgresql.org> <20070410111509.GF24976@svr2.hagander.net> <461B768A.8070402@postgresql.org> <20070410122708.GB25739@svr2.hagander.net> <461B8D60.6080004@postgresql.org> <20070410135708.GA7786@alvh.no-ip.org> <461B9B4F.4070208@postgresql.org> <20070410142535.GB7786@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Tue, 10 Apr 2007 10:25:35 -0400" Date: Tue, 10 Apr 2007 10:42:07 -0400 Message-ID: <25896.1176216127@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200704/32 X-Sequence-Number: 11782 Alvaro Herrera 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