On 2010-06-28 00:02:57 -0400, Stephen Hansen said:
On 6/27/10 8:48 PM, Carl Banks wrote:
I don't know the exact details of all of these, but I'm going to opine
that at least some of these are easily expressible with a function
call API. Perhaps more naturally than with string queries. For
instance, set operations:
query1 = rdb_query(...)
query2 = rdb_query(...)
final_query = rdb_union(query1,query2)
or
final_query = query1& query2
But, see, that's not actually what's going on behind the scenes in the
database. Unless your "query1" and "query2" objects are opaque
pseudo-objects which do not actually represent results -- the query
planners do a *lot* of stuff by looking at the whole query and
computing just how to go about executing all of the instructions.
I believe that *is* his point: that we can replace the SQL language
with a "query object model" that lets us specify what we want without
resorting to string-whacking when our needs are dynamic, without
changing the rest of the workflow. This is obviously true: each RDBMS
does something very much like what Carl is proposing, internally.
However, implementing such an API usefully (never mind comfortably) in
a cross-language way is... difficult, and an RDBMS that can only be
used from Python (or even from Python and other Smalltalk-like
languages) is not terribly useful at all.
-o
--
http://mail.python.org/mailman/listinfo/python-list
