| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us>, Alan Pinstein <apinstein(at)mac(dot)com>, pgsql-bugs(at)postgresql(dot)org | 
| Subject: | Re: BUG #4921: ltree @> ltree[] operator shouldn't fail if ltree[] is empty | 
| Date: | 2010-02-24 17:41:53 | 
| Message-ID: | 19927.1267033313@sss.pgh.pa.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2010-02-24 18:11:10 | Re: [BUGS] BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation | 
| Previous Message | Tom Lane | 2010-02-24 17:16:13 | Re: PostgreSQL-9.0alpha: jade required? |