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

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> <thomas.munro@gmail.com> wrote:
>
> On Sun, Apr 7, 2019 at 3:46 AM Tom Lane <tgl@sss.pgh.pa.us> <tgl@sss.pgh.pa.us> wrote:
>
> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip.rembialkowski@gmail.com> <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