Make all ereport() calls within gram.y provide error locations.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 31 Oct 2024 20:09:22 +0000 (16:09 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 31 Oct 2024 20:09:27 +0000 (16:09 -0400)
commit2d8bff603c9ee7b284b85016fd1a8849ee36368d
tree3a35c313476878bf6199fcae91a4e8111dab4423
parent89e51abcb2905d6beaa09a7d3603d6882ac27033
Make all ereport() calls within gram.y provide error locations.

This patch responds to a comment that I (tgl) made in the
discussion leading up to 774171c4f, that really all errors
occurring during raw parsing should provide error cursors.
Syntax errors reported by Bison will have one, and most of
the handwritten ereport's in gram.y already provide one,
but there were a few stragglers.

(It is not claimed that this handles every failure reachable
during raw parsing --- out-of-memory is an obvious exception.
But this makes a good start on cases that are likely to occur.)

While we're at it, clean up the reported positions for errors
associated with LIMIT/OFFSET clauses.  Previously we were
relying on applying exprLocation() to the contained expressions,
but that leads to slightly odd cursor placement, e.g.

regression=# (select * from foo limit 10) limit 10;
ERROR:  multiple LIMIT clauses not allowed
LINE 1: (select * from foo limit 10) limit 10;
                                           ^

We can afford to keep a little more state in the transient
SelectLimit structs in order to make that better.

Jian He and Tom Lane (extracted from a larger patch by Jian,
with some additional work by me)

Discussion: https://postgr.es/m/CACJufxEmONE3P2En=jopZy1m=cCCUs65M4+1o52MW5og9oaUPA@mail.gmail.com
src/backend/parser/gram.y
src/test/regress/expected/create_table.out
src/test/regress/expected/limit.out
src/test/regress/expected/sqljson.out