Re: fix for BUG #3720: wrong results at using ltree - Mailing list pgsql-hackers

From Ibrar Ahmed
Subject Re: fix for BUG #3720: wrong results at using ltree
Date
Msg-id CALtqXTdy_Nga+8M_RjhHXNZrcFfFQ3rcmJxHUBn-nLpi9ZYbGw@mail.gmail.com
Whole thread Raw
In response to Re: fix for BUG #3720: wrong results at using ltree  (Nikita Glukhov <n.gluhov@postgrespro.ru>)
List pgsql-hackers


On Tue, Jul 16, 2019 at 8:52 PM Nikita Glukhov <n.gluhov@postgrespro.ru> wrote:


On 09.07.2019 17:57, Oleg Bartunov wrote:
On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro <thomas.munro@gmail.com> wrote:
On Sun, Apr 7, 2019 at 3:46 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Filip Rembiałkowski <filip.rembialkowski@gmail.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?
 
Please create separate commitfest entry.

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



--
Ibrar Ahmed

pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: fix for BUG #3720: wrong results at using ltree
Next
From: Peter Eisentraut
Date:
Subject: Re: Unexpected "shared memory block is still in use"