from all libpq-using applications not just psql. We could make this
conditional on the error verbosity --- in "terse" mode the "LINE N"
output wouldn't appear, and "at character N" still would. Applications
should already be expecting multiline outputs from PQerrorMessage if
they're in non-terse
Martijn van Oosterhout writes:
> My only comment is: Wouldn't it be clearer in the long run to create a
> ParseNode base structure which is used in place of NodeTag for
> parsenodes, and put the "int location" in there.
Only if we really wanted *every* parse node to carry a location, which
I thin
[ cross-posting to pgsql-interfaces in hopes of drawing more comments ]
Michael Glaesemann <[EMAIL PROTECTED]> writes:
> On Mar 13, 2006, at 2:37 , Tom Lane wrote:
>> http://archives.postgresql.org/pgsql-patches/2006-03/msg00153.php
> This looks really nice.
>> One thing I'm noticing already is
Dear Tom,
I haven't gone further than making it finger the locations of bogus column
references, operators, and functions --- it's probably worth improving
TypeCast and maybe a few other raw-parse-tree constructs too.
Yes. Other area would also benefit, such as type names:
psql: CREATE FUNCT
> The attached WIP patch improves the parser so that cursor positions
> can be attached to many errors reported during parse analysis, such
> as complaints about nonexistent columns or functions. This is along
> the lines proposed in my rant here:
> http://archives.postgresql.org/pgsql-patches/20
On Mar 13, 2006, at 2:37 , Tom Lane wrote:
to wit, that we make use of bison's "locations" feature to track token
positions in the grammar, and add locations to raw parse tree nodes as
needed.
Some examples of what it can do:
This looks really nice.
One thing I'm noticing already is that th
The attached WIP patch improves the parser so that cursor positions can be
attached to many errors reported during parse analysis, such as complaints
about nonexistent columns or functions. This is along the lines proposed
in my rant here:
http://archives.postgresql.org/pgsql-patches/2006-02/msg00
