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
- 0001-Fix-max-size-checking-for-ltree-and-lquery.patch (text/x-patch)
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
-
Back-patch addition of stack overflow and interrupt checks for lquery.
- fade4d4dffca 11.8 landed
- e48ff22d39db 9.6.18 landed
- cffa57f52cc4 9.5.22 landed
- 94c9152dc880 12.3 landed
- 8b902e438608 10.13 landed
-
Fix lquery's NOT handling, and add ability to quantify non-'*' items.
- 70dc4c509b33 13.0 landed
-
Improve error messages in ltree_in and lquery_in.
- e07e2a40bd0c 13.0 landed
-
Fix lquery's behavior for consecutive '*' items.
- 9950c8aadf0e 13.0 landed
-
Protect against overflow of ltree.numlevel and lquery.numlevel.
- 8e1e630d004e 9.5.22 landed
- 95f7ddfdad99 13.0 landed
- 5feb3d0b3f6b 11.8 landed
- 39491aa0da48 9.6.18 landed
- 2bb6bdbe5da7 12.3 landed
- 2618ac6c6535 10.13 landed