Basic support for prepared statements in postgres, sqlite3 and mysql. #99
Conversation
With this modification we can enjoy the security benefits of having prepared-statement-alike additional parameters. To do this, the additional parameters should be passed after the statement in the execute method. This means that a new prepared statement will be created on each execute call, so don't expect big a performance increase. Maybe in a distant future a LRU cache of prepared statements could be added.
As in SQLite3, we now support prepared-statements-alike passing of
optional parameters by using the PQexecParams function, and since adding
support for binary types is not an easy task, any argument is converted
to a string before being sent and converted back to the expected type by
PostgreSQL... in any case this is better than nothing.
You may want to use a cast ``::type'' if it's not inferred. Example:
> db = require'luasql.postgres'.postgres():connect('')
> assert(db:execute('create table t(a int)'))
> assert(db:execute('insert into t values($1)', 17))
> res = assert(db:execute('select $1+$2::int, a from t where a>$1', 3, 4))
> =res:fetch()
7 17
Since sqlite3_bind_text is binary safe, binding as text can be done without worries.
|
|
This eliminates the need for escaping parameters, since now they can be specified as additional arguments to execute.
fcr--
changed the title
|
This is great news, I'll have a look at getting the ODBC and Firebird drivers working with the non-table parameters style soon. Do you have any plans to expose prepared statements? It's very useful when doing batch work. |
This function can be used by all the drivers simplifying the logic, requiring only to implement conn:prepare(sql) and stmt:execute(...).
|
@blumf Yes, I'm currently implementing those changes into the mysql drivers. Others will follow! |
|
I don't wanna be annoying, but is this ever getting merged? Do you need help merging it? |
|
I too am wondering if this will ever be merged! In late 2014 I was working on a lightweight blogging engine written in lua, when I discovered during coding of the comment form that luasql would make the engine vulnerable to SQL injections. SQL injections are a fatal security flaw for a blogging engine, so I shelved the project. I just came back to the project today, thinking of resurrecting it, but prepared statements are still unsupported. Using lua + MySQL for anything that involves untrusted input really needs this feature. |
Perhaps make a function that acts like prepare (fake prepare), finish your project in development environment only and if prepared statements ever come, you will change this one function only (or find and replace in all files). |
With this modification we can enjoy the security benefits of having
prepared-statement-alike additional parameters. To do this, the
additional parameters should be passed after the statement in the
execute method.
This means that a new prepared statement will be created on each
execute call, so don't expect a huge performance increase. This is
done for safety reasons.