From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Filip Rembiałkowski <filip(dot)rembialkowski(at)gmail(dot)com> |
Cc: | Nikita Glukhov <n(dot)gluhov(at)postgrespro(dot)ru>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>, Oleg Bartunov <obartunov(at)postgrespro(dot)ru>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
Subject: | Re: fix for BUG #3720: wrong results at using ltree |
Date: | 2020-03-30 18:00:42 |
Message-ID: | 23304.1585591242@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
0001-rationalize-ltree-input-errors-2.patch | text/x-diff | 10.5 KB |
0002-ltree-not-fixes-and-better-quantifiers-2.patch | text/x-diff | 23.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexey Kondratov | 2020-03-30 18:02:22 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |
Previous Message | Tom Lane | 2020-03-30 17:51:09 | Re: snapper vs. HEAD |