X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id A921F53AFF for ; Thu, 7 Apr 2005 14:44:34 +0100 (BST) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 77965-01 for ; Thu, 7 Apr 2005 13:44:23 +0000 (GMT) Received: from fed1rmmtao03.cox.net (fed1rmmtao03.cox.net [68.230.241.36]) by svr1.postgresql.org (Postfix) with ESMTP id 6421653AF4 for ; Thu, 7 Apr 2005 14:44:22 +0100 (BST) Received: from [192.168.1.200] (really [68.111.226.8]) by fed1rmmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050407134425.RKXU1282.fed1rmmtao03.cox.net@[192.168.1.200]>; Thu, 7 Apr 2005 09:44:25 -0400 Message-ID: <42553936.2010108@acm.org> Date: Thu, 07 Apr 2005 06:44:22 -0700 From: TJ O'Donnell Reply-To: tjo@acm.org User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-sql@postgresql.org Subject: Re: 9.17.5. Row-wise Comparison References: <200504032037.j33Kb1kh016358@hosting.commandprompt.com> <4254AD87.2030508@acm.org> <13655.1112849262@sss.pgh.pa.us> In-Reply-To: <13655.1112849262@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.002 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200504/79 X-Sequence-Number: 20972 I believe I started the multi-column index thread a few months back, but now that I have it working so well, I'm a bit nervous it might break in future. > if (b > 1) then true > else if (b = 1 and c > 2) then true > else if (b = 1 and c = 2 and d > 3) then true > else false Your spec sql snippet is like an OR, isn't it, instead of an AND as I'm reyling on? After PG is to spec, will the behaviour I now see change? Or is just that PG now allows itself the option to test in any order, not ensuring a sorted result? As I see it, the results will be the same according to spec, just not necessarily in the same order. Thanks for the info, and for getting my meaning in spite of the typos in my sql. TJ Tom Lane wrote: > "TJ O'Donnell" writes: > >>I've been using syntax like >>select a from tbl where (b,c,d) > (1,2,3) >> to mean >>select a from t where b>1 and b>2 and d>3 > > >>But I see in the manual at: >>http://www.postgresql.org/docs/7.4/interactive/functions-comparisons.html#AEN12735 >>that only = and <> operators are supported. Does this section of the manual >>not properly apply to this query? Is the manual in error, or am I >>not understanding? > > > PG's current code acts as you are supposing, but it is broken because it > doesn't follow the SQL spec, and we will change it as soon as someone > gets around to working on it. > > The spec says that this syntax implies a column-by-column ordering, > essentially > > if (b > 1) then true > else if (b = 1 and c > 2) then true > else if (b = 1 and c = 2 and d > 3) then true > else false > > You can find related discussions in the archives from a few months > back. The spec's semantics correspond exactly to the sort ordering > of a multiple-column btree index, and so there are good reasons why we'd > want to provide that behavior even if it weren't mandated by the spec. > > regards, tom lane