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  (Alan Pinstein <apinstein@mac.com>)
Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Marko Kreen
Дата:
Сообщение: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance
Следующее
От: David Wilson
Дата:
Сообщение: Re: [PERFORM] BUG #4919: CREATE USER command slows down system performance