|
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)
|
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