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.