> On 2/19/19, dave <d...@ziggurat29.com> wrote: > > addition, but I have lost a capability relative to the > prior scheme of using > > high query cost along with a special flag communicated in > pIdxInfo->idxNum, > > that being the ablilty to emit contextual info as to why > the query failed. > > Yeah. There is no way to report an error out of xBestIndex. And, in > fact, you would not want to do that because one or more xBestIndex > calls might actually work. Or, there might be multiple xBestIndex > calls that all fail for different reasons, in which case it is unclear > which error should be reported. > > I will ponder your request. In the meantime, you can continue to use > the old method, which still works like it always has. > > -- > D. Richard Hipp
OK, well the theory being that the message would be emitted only when all the candidate plans were tried, and still no solution waa found (I guess at the same spot where the current message is emitted). But maybe that is too late, and any messages set along the way are already gone. As for multiple messages, even just emitting an arbitrary one is useful. These failures happen at design time and the developer incrementally refines his/her query until there were no such errors. I'm not sure if it is possible to happen once a working query has been created. I would think that if you had defined a query that was demonstably solvable once, that any subsequent executions would at worst gravitate to that known working soluton even if the planner tried to do things differently that time (maybe based on data values). OK, for now I will revert to the old method. Cheers! -dave _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
