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 Peter Bex 18 Sep 2019 09:49 UTC
On Wed, Sep 18, 2019 at 12:34:54PM +0300, Lassi Kortela wrote:
> In expansion syntax, I've learned from experience to prefer some kind of
> brackets around the identifier being expanded, instead of only having a
> prefix (dollar sign, colon, etc.)

Yeah, that's probably a good idea.  It balances nicely and allows you to
more easily navigate over them using something like "next expression" in
a proper editor.

> When you use many languages you tend to
> forget what characters are valid in the identifier; the explicit closing
> bracket makes it obvious where the identifier ends. Templating languages
> also tend to use braces around identifiers, and they have to operate in some
> of the most hostile syntactic environments around :p
>
> Maybe even one pair of braces would be enough since the user can choose
> their own placeholder names to avoid any conflicts:
>
>     (sql-execute
>      "INSERT INTO foo VALUES ({myval1}::int, {myval2}::int)"
>      '((myval1 . 1) (myval2 . 2)))

Yeah, I would go for the single braces, there's a lot of duplicate things
in this query already.

So if we had

     (sql-execute
      "INSERT INTO foo VALUES ({myval1}, '{myval2}'::text[])"
      '((myval1 . 1)))

this would simply insert a tuple of 1 and the array with the single
string value 'myval2' into the table, right?  Because myval2 is not
supplied, it gets converted to

   "INSERT INTO foo VALUES ($1, '{myval2}::text[])".

or in MySQL:

   "INSERT INTO foo VALUES (?, '{myval2}::text[])".

I could see some problems with this if the user would incorrectly quote
their expressions.  In the case of

     (sql-execute
      "INSERT INTO foo VALUES ('{myval1}', '{myval2}'::text[])"
      '((myval1 . "hi there")))

it would get translated into the following, because we're doing "dumb"
replacement:

   "INSERT INTO foo VALUES ('$1', '{myval2}::text[])"

or in MySQL:

   "INSERT INTO foo VALUES ('?', '{myval2}::text[])"

With a positional parameter of 'hi there', which will hopefully give
an error message.

Cheers,
Peter