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 19 Sep 2019 14:04 UTC
On Thu, Sep 19, 2019 at 09:53:50AM -0400, John Cowan wrote:
> On Thu, Sep 19, 2019 at 3:20 AM Peter Bex <xxxxxx@more-magic.net> wrote:
> > Are you sure?
>
> Evidently I wasn't. Thanks for doing the research.  Documentation on SQL is
> a maze of twisty web pages, all different.

Yeah, it's a total mess, especially in the commercial DB world.

> > I emphatically disagree.  IMO, the DSL is another layer that lies
> > on top of the underlying DBI.  The DBI layer *must* have a way to
> > separate SQL queries from parameters.
>
> Parameters are slightly better than no parameters, but anonymous parameters
> are extremely easy to get wrong, passing the wrong string to the wrong
> thing (I have certainly done this), plus the need to pass the same value
> twice if your statement needs it twice.  If named parameters were
> pervasive, I'd say "use them", but we know they aren't.  "?" isn't actually
> part of SQL AFAICT, and there are probably databases that don't support
> even that.

I think we have already come to a consensus that we'd translate named
parameters in a somewhat dumb way with the {} placeholder syntax.
We'd convert those placeholders to question marks and positional
arguments for those DBs that only support that, and to use numbered
arguments for those that have it, so you don't need to remember to
manually pass in the arguments in the proper position (or even use them
multiple times if they're referred to multiple times).

> I agree that the DSL is a separate layer.  But between quasiquotation,
> which is Lisp's far superior equivalent to named parameters, and the
> ability to do SQL string escaping in just one place, I think it serves as a
> more-than-satisfactory replacement for question marks.  If you don't use
> the DSL, you've already shot yourself in the foot, but nothing will prevent
> dumb programmers from using string-append (or equivalent), except the fact
> that dumb programmers don't generally wind up using Scheme.  We hope.

My personal opinion is that those DSLs are always going to be woefully
incomplete, so we'll need to make sure that the lower level stuff is
available and as safe as possible.

Cheers,
Peter