Hi, I have reviewed your demands with respect to the test cases that I file. Many of those have already been fixed and implemented, however on the items below I have received contradictory feedback and I can not do anything about them unless the controversies are resolved:

When an offending query is found, substitute all JOINs with STRAIGHT_JOINs to ensure that the plan is preserved, then continue simplifying,

My impression was that Igor was against STRAIGHT_JOINS. Also, I have reduced STRAIGHT_JOIN usage in testing because there are various wrong results that show up when STRAIGHT_JOIN is used. If you are willing to fix those, we can move forward with this idea. FORCE KEY can also be used to preserve the original query plan, but only if it is not held against me that it makes the query unrealistic.

Test the base/normal cases (what normal users will use) first, by negotiating with the feature developer what are the boundaries that define "normal".

Unless someone defines "normal" or we obtain data sets and queries from users, this is not possible.

For instance set normal buffer sizes, do not use empty/single-row tables

Please make up your mind. Timour has said that both empty and single row tables are important for testing. What if automatic simplification reduced some tables to empty or a single row? Should I add some of the rows back?

Test the boundary cases after the main cases have been fixed

Define "boundary". Huge tables? Huge queries? Huge records? Unrealistic buffer sizes? I have been informed only about a single bug that can be called a boundary condition. Have there been any others?

Generate more realistic data in the sense that the generated data should imitate FK relationships, think of real-life distributions of values. For instance keys should be sufficiently selective, as they would be for real-life data. (Igor: 7)

This implies large data sets, which in turn implies that bugs will have larger test cases. At this time, what I see is zero tolerance for test cases larger than 5 rows.

Include both the original *and* the simplified test case in the bub report

I can do this only if the original query and test case will not be held against me. We have been through this before and the large queries have proven to be a source of conflict. Philip Stoev