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
