Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty
Date
Msg-id 19927.1267033313@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
I wrote:
>>> 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.

After looking closer, I see that there are seven different occurrences
of this coding pattern in contrib/ltree.  They all look to be sane for
zero-element arrays but I'm hesitant to decide that they should all
allow multidimensionals.  So I'll go with fix #1 instead.

I don't see any other trouble spots elsewhere.  There are other tests
that require ARR_NDIM() == 1, but they are in contexts that will reject
empty arrays anyway, so I don't feel a need to change them.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL-9.0alpha: jade required?
Next
From: "Maximiliano Salazar"
Date:
Subject: BUG #5346: PostgresSQL ODBC 64 bits download