Skip site navigation (1) Skip section navigation (2)

Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty

From: Alan Pinstein <apinstein(at)mac(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty
Date: 2009-07-15 15:27:58
Message-ID: D0E2518E-950A-485E-80D9-0357395A6B8A@mac.com (view raw or flat)
Thread:
Lists: pgsql-bugs
> Hmm.  ltree has always had that ARR_NDIM == 1 check.  I think the  
> reason
> the behavior changed is that ARRAY(SELECT ...) used to return a NULL  
> for
> zero rows, and now it returns an empty (zero-dimensional) array.

Ah OK that makes sense, especially given the "hack" I used as a  
workaround, which effectively emulates the old behavior.

> I can see two reasonable ways to address this:
>
> * Change the ltree test to reject only ARR_NDIM > 1.
>
> * Drop the ARR_NDIM check altogether, and let it search any sort of
> array.
>
> I'm leaning to #2 myself.  However, there are probably other places  
> with
> the same kind of issue, and in some of them it might make more sense  
> to
> reject multidimensional arrays.

There may be a third option; it seems to me that the assert is there  
more to stop unexpected behavior with arrays of dims of 2 or more.

The real solution might be to just convert a 0-dim array into "null"  
or equivalent and still assert error if dims >= 2?

Alan

In response to

Responses

pgsql-bugs by date

Next:From: Tom LaneDate: 2009-07-15 15:30:26
Subject: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Previous:From: Tom LaneDate: 2009-07-15 15:21:42
Subject: Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group