| 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: | Whole Thread | Raw Message | 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
| 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 |