From: Stephen Hansen on
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.

The engine of a SQL database is a pretty sophisticated little pieces of
coding. Because SQL is declarative, the engine is able to optimize just
how to do everything when it looks at the full query, and even try out a
few different ideas at first before deciding on just which path to take.
(This is an area where parametrized queries is even more important: but
I'm not sure if MySQL does proper prepared queries and caching of
execution plans).

If you go and API it, then you're actually imposing an order on how it
processes the query... unless your API is just a sort of opaque wrapper
for some underlining declarative structure. (Like ORM's try to be)

--

... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

From: Carl Banks on
On Jun 27, 8:52 pm, Stephen Hansen <me+list/pyt...(a)ixokai.io> wrote:
> Then there's the type of SQL that results in DBA's having jobs-- and
> deservedly so. Its *really* a very flexible and powerful language
> capable of doing quite a lot to bend, flex, twist, and interleave that
> data in the server while building up a result set for you.

All right, I get it.

I'm not talking about SQL, I'm talking about RDBs. But I guess it is
important for serious RDBs to support queries complex enough that a
language like SQL is really needed to express it--even if being called
from an expressive language like Python. Not everything is a simple
inner joins. I defer to the community then, as my knowledge of
advanced SQL is minimal.

We'll just have accept the risk of injection attacks as a trade off,
and try to educate people to use placeholders when writing SQL.


Carl Banks
From: Owen Jacobson on
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

From: Carl Banks on
On Jun 27, 9:02 pm, Stephen Hansen <me+list/pyt...(a)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
From: Ben Finney on
Carl Banks <pavlovevidence(a)gmail.com> writes:

> On Jun 27, 8:33 pm, Ben Finney <ben+pyt...(a)benfinney.id.au> wrote:
> > Carl Banks <pavlovevide...(a)gmail.com> writes:
> > > I'm disappointed, usually when you sit on your reinforced soapbox and
> > > pretense the air of infinite expertise you at least use reasonable
> > > logic.
> >
> > Kindly stop inventing straw men to attack; I deny the position you're
> > painting for me.
>
> No, this is not a straw man, you are 100% percent guilty of circular
> logic as I accused you of.

The straw man you attacked is as I quoted above.

The claim of circular logic is a separate point, and I addressed it in
the rest of the message. Like you, I stripped the part of the message
that I was not responding to specifically.

> Plus, I will not kindly do anything for you unless you kindly stop
> being condescending and self-righteous when answering questions and
> start treating people with respect.

I always endeavour to treat people with respect, and I leave it to the
independent reader to decide how successful I am in that endeavour.

Respect for a person, though, entails subjecting that person's
statements to criticism where appropriate. Don't mistake exposure of
flaws for self-righteousness, nor criticism for condescension.

This isn't a forum for discussing my style, so I'll limit this message
to merely addressing these slurs.

--
\ “The long-term solution to mountains of waste is not more |
`\ landfill sites but fewer shopping centres.” —Clive Hamilton, |
_o__) _Affluenza_, 2005 |
Ben Finney