Rethinking parameterized SQL queries John Cowan (27 Feb 2021 01:18 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:13 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:17 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 09:30 UTC)
Re: Rethinking parameterized SQL queries John Cowan (27 Feb 2021 20:08 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 20:36 UTC)
Re: Rethinking parameterized SQL queries John Cowan (27 Feb 2021 22:14 UTC)
Re: Rethinking parameterized SQL queries Peter Bex (28 Feb 2021 10:21 UTC)
Re: Rethinking parameterized SQL queries John Cowan (01 Mar 2021 03:29 UTC)
Re: Rethinking parameterized SQL queries Florian Weimer (27 Feb 2021 12:32 UTC)
Re: Rethinking parameterized SQL queries Lassi Kortela (27 Feb 2021 12:39 UTC)

Re: Rethinking parameterized SQL queries Lassi Kortela 27 Feb 2021 09:30 UTC

You could make a general-purpose escaping framework:

- A proper list ( ... ) is rendered as parentheses with each element
rendered in between, space-separated.

- |(| |)| also renders that way.

- |[| |]| same but with square brackets.

- |{| |}| same but with curly braces.

- Strings are written out as strings according to target language
conventions.

- Numbers, booleans as well.

- Any symbol contained in the literal set is written out as a bareword.
The literal set is customizable for different languages, could be a
parameter object. The SQL library could come with a reasonable standard
set which the Postgres/MySQL diehards can extend to cover the latest syntax.

- Any symbol not in the literal set will have to be explicitly spliced
in using ($type value) notation; a more user-friendly notation should be
found. This is somewhat unwieldy, but discourages people from writing
SQL by hand and stashing their queries into reusable procedures.