[erlang-questions] comma-less lists and tuples

Vlad Dumitrescu <>
Thu Sep 21 20:54:39 CEST 2006


On 9/21/06, Yariv Sadan <> wrote:
> The first reason to use the "quasi-SQL" for is that it *guarantees*
> that you will not expose yourself to SQL injection attacks, whereas
> string contcatentation does not.

Yes, naive string concatenation doesn't. But I guess I didn't express
myself clearly enough: it is not this simple string concatenation that
I compare with ErlSql, but a similar library with the single
difference that the API uses string-sql instead of erlang-sql.

The comparison you make is unfair, because for example
make_str_for_fields/1 is a library function. I bet ten pints of beer
that OtherModule:shown_fields() does something very similar.

So how would this alternative library look like? Taking your example
and without any parse transformations or other non-standard
functionality, I would like to see something like

make_get_related_many_to_many_query(OtherModule, JoinTable, Obj,
WhereClause, ExtraClause) ->
   sql:build("select %L from %L "
                "  where (%s.id=%s.%s "
                "  and %s.%s= %s) "
                "  and (%s) "
                "  %s",
    [OtherModule:shown_fields(),  [OtherModule:table(), JoinTable],
     OtherModule, JoinTable, get_id_field(OtherModule),
     JoinTable, get_id_field(Obj), get_id(Obj),

This can be cleaned up a little (and your erlsql example too) by using
some local variables. %L says the arg is a list of parameters.

If we use a parse transform, the it may look even prettier (in my
eyes, at least)

make_get_related_many_to_many_query(OtherModule, JoinTable, Obj,
WhereClause, ExtraClause) ->
   sql:build("select %%OtherModule:shown_fields() "
                "  from %%[OtherModule:table(), JoinTable] "
                "  where
(%OtherModule.id=%JoinTable.%get_id_field(OtherModule) "
                "  and %JoinTable.%get_id_field(Obj)=%get_id(Obj)) "
                "  and (%WhereClause) "
                "  %ExtraClause").

What sql:build does behind the scenes is an implementation detail. It
may put together strings (like io:format) or it may parse the sql,
build a quasi-sql representation and work with it. As a user I don't
care, as long as it does what it is supposed to do. I don't have to
keep counting nested {}s and []s and to learn what in fact is a new
query language (you already want to introduce new ways to write

BTW, how do you write 'join' statements? The natural way for an erlang
data structure would be {join, {select,...}, {select,...}}, but that
doesn't follow the way the sql looks like.

Having a new query language isn't a bad thing, but then it's not sql.

best regards,

More information about the erlang-questions mailing list