Re: string dollar literals (for luamacro or tokenf)

[Jay Carlson <nop@...>]

On Mon, Jan 23, 2012 at 1:03 PM, Petite Abeille
<petite.abeille@gmail.com> wrote:

> On Jan 23, 2012, at 4:50 AM, Jay Carlson wrote:
>
>> Somebody else can write the SQL prepared statement parser ("SELECT * FROM $foo" -> {"SELECT * FROM ?", {foo}} etc)
>
> Sadly, prepared SQL statement are not meant to substitute object names (e.g. table names), but rather just bind variables.

That makes sense. Before I edited the correctness out of it my
original example in http://place.org/~nop/lua/dollar/dinterp.lua was:

-- q = sql_prepare$"SELECT * FROM recorded where chanid=$chanid
--     AND starttime=$starttime"
-- [becomes]
--   {"SELECT * FROM recorded WHERE chanid=? AND starttime=?", {7, 2000}}

> To add insult to injury, bind variable placeholders vary from database to database. Oh, well...

It's a shame that db driver authors actually have to do some work.

> select * from foo where bar = ?
>
> Which could simply be done as string.format if one doesn't have support for proper prepared statements (e.g. luasql):

Oh. My. From http://www.keplerproject.org/luasql/examples.html:

====
list = {{ name="Jose das Couves", email="jose@couves.com", }, {
name="Manoel Joaquim", email="manoel.joaquim@cafundo.com", }, {
name="Maria das Dores", email="maria@dores.com", },}
for i, p in pairs (list) do
  res = assert (con:execute(string.format([[
    INSERT INTO people
    VALUES ('%s', '%s')]], p.name, p.email)
  ))
end
====

I hear Bobby Tables is looking for a foreign exchange school
somewhere. Brazil is nice...

http://bobby-tables.com/

People were talking about hash DoSes being showstoppers for Lua
deployment. I made fun of the term "showstopper", but Lua SQLl just
went on my "never deploy this" list.

> ( 'select * from foo where bar = %s' ):format( escape( baz ) )

This should get out of the view of application programmers. When
string escaping has to be managed constantly and at all levels, simple
things are either difficult or perilous. The costs of this perhaps
reached a high point with PHP4, but it is unclear to me whether PHP is
a wry inside joke like INTERCAL[1]; although there is not a perfect
language for all tasks, those two prove there are languages that just
suck for all tasks. I know we're supposed to avoid argument by saying
"use the right tool for the job" but there is little call for a hammer
with a knife for a handle.

In my opinion, the DB layer should only traffic in constructed query
objects, not strings directly. It should be *easy* to use paramerized
queries, easy enough that nobody ever does string operations on a SQL
SELECT statement for substitution of literals.

This can look like it's string interpolation with a "$foo" syntax, but
because it's actually a parsed language, we will know that whatever is
in foo will not drop some tables for us.

Jay

[1]: Similarly, I am not certain whether Ruby's (perhaps former)
position on non-octet strings (no normalization to Unicode, instead
carry around encoding information) is mockery of the developers like
me 20 years ago who said  "the whole world speaks Latin-1" and
proceeded to make a giant mess out of MBCS with code pages etc etc
etc. Ruby's position certainly is a reasonable position if preventing
change to SJIS performance and code is critical, but then so were all
of the stupid things the ISO Latin-1 world did. Witness the disaster
when you try to include a quotation in Arabic script into a Japanese
text. Wait, which encoding are we using? Don't worry, there's at least
one important script not coded in it. Dutch, for starters :-/