On Wed, Sep 18, 2019 at 01:30:13PM +0300, Lassi Kortela wrote:
> Putting {} in the symbol names does look like deliberately shooting oneself
> in the foot :)

Sure, but I'm not sure the API needs to take too much effort to prevent
people from doing it.

> >      (query "SELECT $2, $3" 1 2 3)
> >
> > It won't give an error about $1 not being used, but it does give an error
> > about not being able to figure out the type of parameter 1.  I don't know
> > if it will _always_ do this, though.
>
> For the love of god :D With this design mentality across the board, it's a
> wonder most websites aren't pwned by now.

Yeah, that's a bit awkward but it's no different from a procedure in a
programming language not using one of its positional arguments.

> I would solve this by having a set of SQL combinators that can be used to
> safely compose whole statements from reusable parts. Something like Roda in
> Ruby is a good example. Any way of doing it with string concatenation just
> turns into misery. So it's best to hide the string concatenation behind a
> DSL.
>
> IIRC you mentioned earlier that there are problems with such DSLs not
> covering advanced features of particular DB engines. This may have to be
> handled by having some kind of (verbatim ...) escape hatch in the DSL to
> inject (no pun intended) arbitrary SQL.

That could work, if it's well-designed.

> In light of such a DSL, maybe you're right that the templating macro is too
> fancy. But I'd still prefer any "raw strings with magic templating" API to
> have some kind of name that hints "please only use this if you know what you
> are doing".

You could use a sort of taint mechanism where you must wrap the SQL
strings in an object to ensure that it's been safely processed.  But I
also think that makes the common case annoying to use.

The current API shouldn't try to do too much, IMO; we're just looking
for an abstraction over database drivers and abstracting away the surface
differences.  I mean, in the Scheme base language itself we also don't
have a pathname abstraction for the file operations, even though
programmatically composing pathnames is tricky business and tends to
be done a *lot*.

I'd say providing a safer way to write SQL is the job of a higher level
library.

Cheers,
Peter