Horton

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

Nikita Glukhov <n.gluhov@postgrespro.ru>

View thread View on postgr.es
From: Nikita Glukhov <n.gluhov@postgrespro.ru>
To: Tom Lane <tgl@sss.pgh.pa.us>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Cc: Filip Rembiałkowski <filip.rembialkowski@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Oleg Bartunov <obartunov@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>
Date: 2020-03-30T22:22:19Z
Lists: pgsql-hackers 
On 31.03.2020 1:12, Tom Lane wrote:

> I wrote:
>> I dunno, that doesn't really seem clearer to me (although some of it
>> might be that you expended no effort on making the comments match
>> the new code logic).
> ... although looking closer, this formulation does have one very nice
> advantage: for the typical non-star case with high = low = 1, the
> only recursive call is a tail recursion, so it ought to consume less
> stack space than what I wrote.

And we even can simply transform this tail call into a loop:

-if (tlen > 0 && qlen > 0)
+while (tlen > 0 && qlen > 0)

> Let me see what I can do with the comments.

Thanks.

-- 
Nikita Glukhov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Commits

  1. Back-patch addition of stack overflow and interrupt checks for lquery.

  2. Fix lquery's NOT handling, and add ability to quantify non-'*' items.

  3. Improve error messages in ltree_in and lquery_in.

  4. Fix lquery's behavior for consecutive '*' items.

  5. Protect against overflow of ltree.numlevel and lquery.numlevel.