> 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/msg00234.php
> 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.
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.
Then you could create a new function called makeParseNode which works
like makeNode but takes an extra argument giving the location. Or some
variation of the two.
The thing I'm wondering is whether there will ever be any other
information we want to store, like token length so you can bracket the
expression and/or extract the exact expression with the issue. For
example, the (start,end) of a function call includes everything within
the brackets. By abstrating into a makeParseNode function, you may be
able to avoid changing a lot of code down the line.
Finally, is the count in characters or bytes (w.r.t. multibyte
encodings)?
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.
