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
Bruce Momjian writes:
> Tom Lane 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 pr
Tom Lane wrote:
> Bruce Momjian writes:
> > Was this ever addressed?
>
> No, it doesn't look like the code's been changed. I was looking for
> some comments about which to do:
>
> >> I can see two reasonable ways to address this:
> >>
> >> * Change the ltree test to reject only ARR_NDIM > 1.
>
Bruce Momjian writes:
> Was this ever addressed?
No, it doesn't look like the code's been changed. I was looking for
some comments about which to do:
>> I can see two reasonable ways to address this:
>>
>> * Change the ltree test to reject only ARR_NDIM > 1.
>>
>> * Drop the ARR_NDIM check al
Was this ever addressed?
---
Tom Lane wrote:
> "Alan Pinstein" writes:
> > ... hierarchy @> ARRAY(select hierarchy from
> > feature where description ilike '%pool%this%') ...
>
> > EXPECTED BEHAVIOR:
> > - return 0 rows
Yeah, and I don't feel I know enough to answer that.
Thanks for responding! Good luck with your decision.
Regards,
Alan
On Jul 15, 2009, at 11:33 AM, Tom Lane wrote:
Alan Pinstein writes:
The real solution might be to just convert a 0-dim array into "null"
or equivalent and still assert er
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.
Ah OK that makes sense, especially given the "hack" I used as a
workaround, whi
Alan Pinstein writes:
> The real solution might be to just convert a 0-dim array into "null"
> or equivalent and still assert error if dims >= 2?
That's my alternative #1. The question is whether there's any real
point in rejecting multi-dimensional arrays here, rather than just
searching all
"Alan Pinstein" 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/
The following bug has been logged online:
Bug reference: 4921
Logged by: Alan Pinstein
Email address: apinst...@mac.com
PostgreSQL version: 8.3.6
Operating system: linux/centos 5.3
Description:ltree @> ltree[] operator shouldn't fail if ltree[] is
empty
Details:
The
10 matches
Mail list logo
