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

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

>
> 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> <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> <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip(dot)rembialkowski(at)gmail(dot)com> <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?
>
>
> Please create separate commitfest entry.

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

--
Ibrar Ahmed