X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 15B7E5280F for ; Mon, 6 Jun 2005 22:24:58 -0300 (ADT) 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 65380-01 for ; Tue, 7 Jun 2005 01:24:49 +0000 (GMT) Received: from joeconway.com (wsip-24-249-201-67.sd.sd.cox.net [24.249.201.67]) by svr1.postgresql.org (Postfix) with ESMTP id 067CB5289E for ; Mon, 6 Jun 2005 22:24:48 -0300 (ADT) Received: from [192.168.4.1] (account jconway [192.168.4.1] verified) by joeconway.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 2887935; Mon, 06 Jun 2005 19:22:12 -0700 Message-ID: <42A4F764.9010705@joeconway.com> Date: Mon, 06 Jun 2005 18:24:52 -0700 From: Joe Conway User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Fedora/1.7.6-1.2.5 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?TWFya3VzIEJlcnRoZWF1IOKYrQ==?= Cc: pgsql-hackers@postgresql.org, Tom Lane Subject: Re: [SQL] ARRAY() returning NULL instead of ARRAY[] resp. References: <1116873219.7306.0.camel@localhost.localdomain> <42923762.7010708@joeconway.com> <16774.1116907560@sss.pgh.pa.us> <1118067445.5506.6.camel@dicaprio.akademie1.de> <25974.1118069089@sss.pgh.pa.us> <1118069699.5506.9.camel@dicaprio.akademie1.de> <42A470B5.8060007@joeconway.com> <42A472A4.6090505@joeconway.com> <1118074367.5506.16.camel@dicaprio.akademie1.de> In-Reply-To: <1118074367.5506.16.camel@dicaprio.akademie1.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.054 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200506/273 X-Sequence-Number: 68754 Markus Bertheau ☭ wrote: > Hmm, this gets really complicated and inconsistent. Complicated means > unusable. What about modifying the dimension syntax such that the second > number means number of elements instead of upper bound? That particular > problem would go away then, and array_upper('[0:0]={}'::int[]) can > return the correct 0 then. > > What I'm actually worrying about is that array_upper(array(select 1 > where false)) returns 0. > > An option would be to drop the possibility to let the array start at > another index than 0. I don't know why it was decided to do that in the > first place. It seems a rather odd feature to me. > Actually I like both of these ideas, and have advocated the second one myself before. But it isn't backward compatible -- anyone else have an opinion? SQL2003 actually specifies that an array *should* start at 1: 4.10.2 Arrays An array is a collection A in which each element is associated with exactly one ordinal position in A. If n is the cardinality of A, then the ordinal position p of an element is an integer in the range 1 (one) ≤ p ≤ n. Joe