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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com>
Cc: Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>
Subject: Re: fix for BUG #3720: wrong results at using ltree
Date: 2019-04-06 15:46:02
Message-ID: 28639.1554565562@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

=?UTF-8?Q?Filip_Rembia=C5=82kowski?= <filip(dot)rembialkowski(at)gmail(dot)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

I took a quick look through this. I see where you're going with this,
and I agree that this coding seems like a better match to what it says
in the documentation:

... you can put ! (NOT) at the start to match any label that
doesn't match any of the alternatives.

However, it seems like Teodor and Oleg went to an awful lot of trouble
to implement some other behavior. It looks like what's there is trying
to do something like "true if this pattern does not match any label
between the matches for whatever's around it", rather than just "true
if this pattern does not match at one specific position". The number
of changes in the expected output for existing regression test cases
is also disheartening: it's fairly hard to believe that whoever wrote
the test cases didn't think those expected outputs were correct.

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.

BTW, if we do proceed in this direction, I wonder whether the
ltree_gist code needs any adjustments.

Thoughts?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2019-04-06 16:26:30 pgbench - add minimal stats on initialization
Previous Message Andrew Dunstan 2019-04-06 15:24:11 Re: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation