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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Alan Pinstein" <apinstein(at)mac(dot)com>
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:21:42
Message-ID: 23006.1247671302@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Alan Pinstein" <apinstein(at)mac(dot)com> writes:
> ... hierarchy @> ARRAY(select hierarchy from
> feature where description ilike '%pool%this%') ...

> EXPECTED BEHAVIOR:
> - return 0 rows

> ACTUAL BEHAVIOR:
> ERROR: array must be one-dimensional
> Possibly from:
> https://projects.commandprompt.com/public/replicator/browser/trunk/contrib/ltree/_ltree_op.c?rev=1905 line 46

> NOTES:
> This query worked in 8.1.x and started failing in 8.3.6 (only 2 versions I
> tested).

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.

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Alan Pinstein 2009-07-15 15:27:58 Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty
Previous Message David Wilson 2009-07-15 15:16:23 Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance