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: Filip Rembiałkowski <filip.rembialkowski@gmail.com>
Cc: Nikita Glukhov <n.gluhov@postgrespro.ru>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, Pgsql Hackers <pgsql-hackers@postgresql.org>, Oleg Bartunov <obartunov@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, Teodor Sigaev <teodor@sigaev.ru>
Date: 2020-03-30T18:00:42Z
Lists: pgsql-hackers

Attachments

I wrote:
> Hence, attached are two revised patches that attack the problem
> this way.  The first one is somewhat unrelated to the original
> point --- it's trying to clean up the error messages in ltree_in
> and lquery_in so that they are more consistent and agree with
> the terminology used in the documentation.  (Notably, the term
> "level" is used nowhere in the ltree docs, except in the legacy
> function name nlevel().)

One thing I changed in that patch was to change the syntax error
reports to say "at character %d" not "in position %d", because
I thought the latter was pretty confusing --- it's not obvious
whether it's counting characters or labels or what.  However,
I now notice that what the code is providing is a zero-based
character index, which is out of line with our practice
elsewhere: core parser errors are reported using 1-based indexes.
If we reword these messages then we should adopt that practice too.
Hence, new patch versions that do it like that.  (0002 is unchanged.)

			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.