Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Nikita Glukhov <n.gluhov@postgrespro.ru>
Cc: Filip Rembiałkowski <filip.rembialkowski@gmail.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>, 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:12:42Z
Lists: pgsql-hackers 
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.

Let me see what I can do with the comments.

			regards, tom lane

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.