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 334B2528A8 for ; Mon, 6 Jun 2005 13:13:01 -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 23772-07 for ; Mon, 6 Jun 2005 16:12:58 +0000 (GMT) Received: from web11.manitu.net (web11.manitu.net [217.11.48.111]) by svr1.postgresql.org (Postfix) with ESMTP id 252A152891 for ; Mon, 6 Jun 2005 13:12:56 -0300 (ADT) Received: from dicaprio.akademie1.de (dicaprio.akademie1.de [62.165.4.166]) (authenticated) by web11.manitu.net (8.10.2-SOL3/8.10.2) with ESMTP id j56GCpT26467; Mon, 6 Jun 2005 18:12:51 +0200 Subject: Re: [SQL] ARRAY() returning NULL instead of ARRAY[] From: Markus Bertheau =?UTF-8?Q?=E2=98=AD?= To: Joe Conway Cc: pgsql-hackers@postgresql.org, Tom Lane In-Reply-To: <42A472A4.6090505@joeconway.com> 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> Content-Type: text/plain; charset=utf-8 Date: Mon, 06 Jun 2005 18:12:46 +0200 Message-Id: <1118074367.5506.16.camel@dicaprio.akademie1.de> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.016 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/248 X-Sequence-Number: 68729 В Пнд, 06/06/2005 в 08:58 -0700, Joe Conway пишет: > Joe Conway wrote: > > Actually, consistent with my last post, I think array_upper() on a > > zero-element array should return NULL. A zero-element array has a > > defined lower bound, but its upper bound is not zero -- it is really > > undefined. > > Just to clarify my response, this is what I propose: > > regression=# select array_upper('[2][1:]={{},{}}'::int[],1); > array_upper > ------------- > 2 > (1 row) > > regression=# select array_upper('[2][1:]={{},{}}'::int[],2) IS NULL; > ?column? > ---------- > t > (1 row) 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. Markus -- Markus Bertheau ☭