Email list hosting service & mailing list manager

Named vs numbered SQL parameters Lassi Kortela (18 Sep 2019 08:48 UTC)
Re: Named vs numbered SQL parameters Peter Bex (18 Sep 2019 09:13 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (18 Sep 2019 09:35 UTC)
Re: Named vs numbered SQL parameters Peter Bex (18 Sep 2019 09:49 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (18 Sep 2019 10:10 UTC)
Re: Named vs numbered SQL parameters Peter Bex (18 Sep 2019 10:16 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (18 Sep 2019 10:30 UTC)
Re: Named vs numbered SQL parameters Peter Bex (18 Sep 2019 10:38 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (18 Sep 2019 10:50 UTC)
Re: Named vs numbered SQL parameters Alaric Snell-Pym (18 Sep 2019 10:39 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (19 Sep 2019 14:20 UTC)
Re: Named vs numbered SQL parameters Peter Bex (19 Sep 2019 14:53 UTC)
Re: Named vs numbered SQL parameters Alaric Snell-Pym (19 Sep 2019 16:05 UTC)
Re: Named vs numbered SQL parameters John Cowan (18 Sep 2019 22:36 UTC)
Re: Named vs numbered SQL parameters Peter Bex (19 Sep 2019 07:20 UTC)
Re: Named vs numbered SQL parameters John Cowan (19 Sep 2019 13:54 UTC)
Re: Named vs numbered SQL parameters Peter Bex (19 Sep 2019 14:04 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (19 Sep 2019 14:07 UTC)
Re: Named vs numbered SQL parameters Peter Bex (19 Sep 2019 14:19 UTC)
Re: Named vs numbered SQL parameters Lassi Kortela (19 Sep 2019 14:28 UTC)
Re: Named vs numbered SQL parameters Alaric Snell-Pym (19 Sep 2019 16:00 UTC)

Re: Named vs numbered SQL parameters Alaric Snell-Pym 18 Sep 2019 10:39 UTC
On 18/09/2019 10:13, Peter Bex wrote:

> We could use a really really stupid approach and simply replace any
> placeholder with its exact string.
>
> So for example
>
> (sql-execute "INSERT INTO foo VALUES (:myval1, :myval2)"
>              '((:myval1 . 1) (:myval2 . 2)))
>
> If the query gets messed up the user should simply choose better
> placeholders.

Eargh!

> I see PDO actually includes an SQL parser in order to be able to replace
> their questionmark-based parameter handling:
> https://github.com/php/php-src/blob/master/ext/pdo/pdo_sql_parser.re#L51

Eurgh!

> I don't really want to go down this route, it is too complicated for a
> straightforward database abstraction.  And as the Stack Overflow post
> showed, it's too brittle to get right (SQL is a pain to parse, especially
> with all the extensions that various dialects throw onto it).

Oh yes. I've had maintain an SQL parser. :-|

Here's an ugly but safe option to consider - pass in the query as a list
of strings and symbols, where the symbols are to be replaced by
appropriate DB-specific magic and the strings stitched together around them:

(sql-execute '("INSERT INTO foo VALUES(" myval1 ", " myval2 ")")
             '((:myval1 . 1) (:myval2 . 2)))

However, the later suggestion of {myval1} also looks good!

But I always prefer the SSQL approach to this of just shoving scheme
values in using quasiquoting:

(sql-execute `(insert (into foo)
                      (values #(,myval1 ,myval2)))

>
> Cheers,
> Peter
>

--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/