As Larry mentioned, just what do we mean when we say "query builder?" And just exactly why do we need one? Let's try to be specific and write out both a definition and the reasons for having one in Drupal core. What are the benefits? What are the drawbacks? And, what are the alternatives? Maybe some other form of abstraction would actually be a better choice for Drupal core. Here is starting point on some specifics. * Definition of a query builder (in our context and plans) -- Are we discussing the constuction of something that will take all of the "normal" database queries needed to generate a page into consideration and then build a more optimal, smaller number of queries to retrieve the data (per Larry's remark about views saving a ton of SQL by doing something along these lines)? * Reasons for having a query builder in core -- Saving developers from struggling with complex code to retrieve data, at the cost of SQL statement complexity and performance. -- Possibly optimize number of queries per page. * Possible Alternative Abstractions (just blue sky ideas at this point) -- Define once and for all the first class objects for core, and write CRUD operations for the _objects_. -- Abstraction library maintained by "core SQL" developers, through which all access will flow. Let's be explicit about what we are really trying to accomplish -- the goal, not the implementation -- and then detail the characteristics of an implementation which will attain that goal. This is too key and too large an effort to be less rigorous about it, I think.