Re: fix for BUG #3720: wrong results at using ltree
От | Nikita Glukhov |
---|---|
Тема | Re: fix for BUG #3720: wrong results at using ltree |
Дата | |
Msg-id | 5eedfd9e-2f14-a2df-3bd9-4c92eb0f08a5@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: fix for BUG #3720: wrong results at using ltree (Oleg Bartunov <obartunov@postgrespro.ru>) |
Ответы |
Re: fix for BUG #3720: wrong results at using ltree
Re: fix for BUG #3720: wrong results at using ltree Re: fix for BUG #3720: wrong results at using ltree |
Список | pgsql-hackers |
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? -- Nikita Glukhov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: