Gambit FFI implementation of minimal SQLite3 interface
Lassi Kortela
(31 Aug 2020 08:52 UTC)
|
Re: Gambit FFI implementation of minimal SQLite3 interface
John Cowan
(01 Sep 2020 21:54 UTC)
|
Re: Gambit FFI implementation of minimal SQLite3 interface Lassi Kortela (02 Sep 2020 05:33 UTC)
|
Do we need to support positional parameters to SQL prepared statements?
Lassi Kortela
(02 Sep 2020 05:44 UTC)
|
Re: Do we need to support positional parameters to SQL prepared statements?
John Cowan
(02 Sep 2020 22:57 UTC)
|
Re: Gambit FFI implementation of minimal SQLite3 interface
Lassi Kortela
(02 Sep 2020 07:33 UTC)
|
Re: Gambit FFI implementation of minimal SQLite3 interface Lassi Kortela 02 Sep 2020 05:33 UTC
>> It doesn't do parameters yet because we haven't agreed on the syntax. > Since we aren't doing any substitutions ourselves, we don't need to know > what the parameter markers are: you can use sqlite3_bind_parameter_name > to get the names of those in use, and > sqlite3_bind_{int,double,text,blob,null} to set their values. Good. I'll implement that. > But since you ask, @name is in my opinion the best of SQLite's choices; > it is reasonably portable and uses names rather than numbers or > positions, which are extremely error-prone. The others are ? > (positional), ?nnn (numeric), :name, and $name. Is @name a de facto standard for named parameters? Does ANSI SQL have any standard parameter markers? Would it be a problem to leave out support for positional parameters entirely? I agree that positional ones are error-prone except for the simplest statements. Similarly, the usability of Python's str.format() improved a lot once it started taking named parameters as keyword arguments.