On Jun 27, 3:20 pm, Roy Smith <r...@panix.com> wrote: > In article > <14e44c9c-04d9-452d-b544-498adfaf7...@d8g2000yqf.googlegroups.com>, > Carl Banks <pavlovevide...@gmail.com> wrote: > > > > > Seriously, almost every other kind of library uses a binary API. What > > makes databases so special that they need a string-command based API? > > How about this instead (where this a direct binary interface to the > > library): > > > results = rdb_query(table = model, > > columns = [model.name, model.number]) > > > results = rdb_inner_join(tables = [records,tags], > > joins = [(records.id,tags.record_id)]), > > columns = [record.name, tag.name]) > > > Well, we know the real reason is that C, Java, and friends lack > > expressiveness and so constructing a binary query is an ASCII > > nightmare. Still, it hasn't stopped binary APIs in other kinds of > > libraries. > > Well, the answer to that one is simple. SQL, in the hands of somebody > like me, can be used to express a few pathetic joins and what I do with > it could probably be handled with the kind of API you're describing. > But, the language has far more expressivity than that, and a > domain-specific language is really a good fit for what it can do.
I'm not the biggest expert on SQL ever, but the only thing I can think of is expressions. Statements don't express anything very complex, and could straightforwardly be represented by function calls. But it's a fair point. > The problem is not so much that SQL queries are described as text > strings, No, it is the problem, or part of it. String commands are inherently prone to injection attacks, that's the main problem with them. > but that the distinction between program and data gets lost if > you build the query as one big string. That too. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
