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 20:36 UTC

>     If a complete SQL grammar covering the major DB engines is too hard,
>
> It's unthinkable at this point.  See
> <https://www.more-magic.net/posts/lispy-dsl-ssql.html> (Peter Bex aka
> sjaaman) for an overview of the issues, and
> <https://ronsavage.github.io/SQL/>
> for BNF grammars of SQL-92, -99, and -2003.

I believe you and your sources.

> The last confirms that SQL-2003 uses ? in several places, but ~ is still
> free (and more Lispy: see CL format and SRFIs 28 and 48).

Free for now. ~ is used for complement or negation in several languages.

>     (insert into foo values (bar |,| baz))
>
>     which is literal, except that ($type value) escapes that can poke holes
>     in it and inject variables. You could have many categories:
>
> For my efforts in this direction, see
> <https://github.com/johnwcowan/r7rs-work/blob/master/AgnosticSql.md
> Warning: "agnostic SQL" usually means "works with databases X, Y, and Z,
> and if you send us code for database Q, great!"  That's not the case
> here.  I gave up eventually because it started to look too complicated.
> A featurectomy might make it feasible.

A valiant effort, but Peter has to be right.

We could try our hand at defining the "ANSI + reasonable extensions" DSL.

> If you go to <https://www.more-magic.net/archive.html
> <https://www.more-magic.net/archive.html>> you can see Peter's comments
> on S-expression DSLs for CSS, regular expressions, and XML (tl;dr
> version: CSS doable but not really ready yet, irregex / SRFI 115 and
> SXML work well).

I read those last year; IIRC he's talking about the semantics level
grammar, not a dumb token-level representation.

In a token-level representation, each bracket like '|[| is just a dumb
token, and is not parsed for meaning (we could check that brackets
match, but that's about it). The only things we'd be concerned with is
how to quote string literals and how to represent numbers and the like.