Re: fix for BUG #3720: wrong results at using ltree

On 09.07.2019 17:57, Oleg Bartunov wrote:
> On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>> On Sun, Apr 7, 2019 at 3:46 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip(dot)rembialkowski(at)gmail(dot)com> writes:
>>>> Here is my attempt to fix a 12-years old ltree bug (which is a todo item).
>>>> I see it's not backward-compatible, but in my understanding that's
>>>> what is documented. Previous behavior was inconsistent with
>>>> documentation (where single asterisk should match zero or more
>>>> labels).
>>>> http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php
>> [...]
>>
>>> In short, I'm wondering if we should treat this as a documentation
>>> bug not a code bug. But to do that, we'd need a more accurate
>>> description of what the code is supposed to do, because the statement
>>> quoted above is certainly not a match to the actual behavior.
>> This patch doesn't apply. More importantly, it seems like we don't
>> have a consensus on whether we want it.
>>
>> Teodor, Oleg, would you like to offer an opinion here? If I
>> understand correctly, the choices are doc change, code/comment change
>> or WONT_FIX. This seems to be an entry that we can bring to a
>> conclusion in this CF with some input from the ltree experts.
> We are currently very busy and will look at the problem (and dig into
> our memory) later. There is also another ltree patch
> (https://commitfest.postgresql.org/23/1977/), it would be nice if
> Filip try it.

I looked at "ltree syntax improvement" patch and found two more very
old bugs in ltree/lquery (fixes are attached):

1. ltree/lquery level counter overflow is wrongly checked:

SELECT nlevel((repeat('a.', 65534) || 'a')::ltree);
nlevel
--------
65535
(1 row)

-- expected 65536 or error
SELECT nlevel((repeat('a.', 65535) || 'a')::ltree);
nlevel
--------
0
(1 row)

-- expected 65537 or error
SELECT nlevel((repeat('a.', 65536) || 'a')::ltree);
nlevel
--------
1
(1 row)

-- expected 'aaaaa...' or error
SELECT (repeat('a.', 65535) || 'a')::ltree;
ltree
-------

(1 row)

-- expected 'aaaaa...' or error
SELECT (repeat('a.', 65536) || 'a')::ltree;
ltree
-------
a
(1 row)

2. '*{a}.*{b}.*{c}' is not equivalent to '*{a+b+c}' (as I expect):

SELECT ltree '1.2' ~ '*{2}';
?column?
----------
t
(1 row)

-- expected true
SELECT ltree '1.2' ~ '*{1}.*{1}';
?column?
----------
f
(1 row)

Maybe these two bugs need a separate thread?

--
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company