On Jun 27, 9:02 pm, Stephen Hansen <me+list/pyt...@ixokai.io> wrote: > 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
That's exactly what they are. Nothing is actually sent to the database until the user starts retrieving results. This is fairly common thing for some interfaces to do. For instance, OpenGL almost always returns immediately after a command is posted without doing anything. The driver will queue the command in memory until some event happens to trigger it (maybe a signal from the graphics that is is done processing commands, or the queue being full, or an explicit flush request from the user). Incidentally, OpenGL has its own DSL for per-vertex and per-pixel operations (known as vertex and fragment shaders) that replaces an older binary API. I daresay it's a little less at risk for an injection attack, seeing that the shaders run on the GPU and only run simple math operations. But you never know. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
