Created attachment 75342 [details]
typescript with warnings
The referenced warning message has been mentioned in
bug 60504 "EDITING: Sort removes brackets in Queries - Sorting
doesn't work in correlated Subqueries"
bug 60539 "FILESAVE: Column-width of a Query couldn't be saved"
bug 61203 "SQL syntax error inserting new record into empty table"
I am creating this report to deal with the possibility that it is
independent of those other problems.
steps to reproduce ...
(1) Download the .odb file attached to bug 61193
(2) At command line, open the file.
Program displays window "New Database1.odb"
(3) In the left pane, click <Tables>.
Program displays table name OneColumn in the lower right pane.
(4) In the lower right pane right-click OneColumn and on the pop-up
menu select Open.
Program displays Table Data View window. In the terminal window,
observe numerous warnings like the following, but with an
assortment of _nRule's ...
warn:connectivity.parse:1104:1:workdir/unxlngi6/YaccTarget/connectivity/source/parse/sqlbison.cxx:9223: connectivity::OSQLParser::RuleIDToRule cannot reverse-lookup rule. Reverse mapping incomplete? _nRule='383' yytname[_nRule]='opt_fetch_first_clause'
The attached typescript has 77 instances of the warning. Doing some
counting gives us ...
_nRule times yytname[_nRule]
------ ----- ------------------------
367 15 opt_all_distinct
378 10 opt_result_offset_clause
383 10 opt_fetch_first_clause
387 10 opt_limit_offset_clause
398 10 opt_group_by_clause
400 10 opt_having_clause
418 2 null_predicate_part_2
489 10 opt_window_clause
I observed this with master commit 2e367c0, pulled around 2013-02-17,
built and running on ubuntu-natty (11.04) 32-bit. My configuration
options are ...
The warning was introduced into sqlbison.y on 2013-01-23 by
I have no idea whether the problem lies in the inability to do the
reverse lookup or in the expectation that it should be possible to do
that lookup. Any suggestions, Lionel?
Some of these warnings could hint at an underlying problem, but not necessarily. Unless there is some reason to believe the bug being investigated could be linked, ignore them. It all depends whether the calling code has a good default case for "UNKOWN_RULE". If it has (it does not need to do anything "special" with the node it tries to reverse-lookup), then no problem.
Possibly I've just been too verbose by putting these warnings <shrug>