Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty
От | Tom Lane |
---|---|
Тема | Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty |
Дата | |
Msg-id | 23006.1247671302@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty ("Alan Pinstein" <apinstein@mac.com>) |
Ответы |
Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if
ltree[] is empty
Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty |
Список | pgsql-bugs |
"Alan Pinstein" <apinstein@mac.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
В списке pgsql-bugs по дате отправления: