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

Nikita Glukhov <n.gluhov@postgrespro.ru>

From: Nikita Glukhov <n.gluhov@postgrespro.ru>
To: Oleg Bartunov <obartunov@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Filip Rembiałkowski <filip.rembialkowski@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>
Date: 2019-07-16T15:50:22Z
Lists: pgsql-hackers

Attachments

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:
>>> =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <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?


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

Commits

  1. Back-patch addition of stack overflow and interrupt checks for lquery.

  2. Fix lquery's NOT handling, and add ability to quantify non-'*' items.

  3. Improve error messages in ltree_in and lquery_in.

  4. Fix lquery's behavior for consecutive '*' items.

  5. Protect against overflow of ltree.numlevel and lquery.numlevel.