On Tue, Jul 16, 2019 at 8:52 PM Nikita Glukhov <n.glu...@postgrespro.ru> wrote:
> > On 09.07.2019 17:57, Oleg Bartunov wrote: > > On Mon, Jul 8, 2019 at 7:22 AM Thomas Munro <thomas.mu...@gmail.com> > <thomas.mu...@gmail.com> wrote: > > On Sun, Apr 7, 2019 at 3:46 AM Tom Lane <t...@sss.pgh.pa.us> > <t...@sss.pgh.pa.us> wrote: > > =?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip.rembialkow...@gmail.com> > <filip.rembialkow...@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
