> 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 <email@example.com> 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.
Description: Digital signature