bug#25628: 26.0.50; [PATCH] sql-mode w/ sqlite: In-memory database

[rolf@linux-qg7d.i-did-not-set--mail-host-address--so-tickle-me]

Am 03/02/2017 02:35 PM, npostavs@users.sourceforge.net wrote:
> 
>> From: Rolf Ade <rolf@pointsman.de> Date: Sun, 5 Feb 2017 19:46:24
>> +0100 Subject: [PATCH] sql-mode w/ sqlite: In-memory database
>> 
>> Enable the usage of an in-memory database. Prior to this, sql-mode
>> w/ sqlite could only be used with file databases. *
>> list/progmodes/sql.el (sql-get-login-ext): Don't expand an empty 
>> file name provided by the user, but call sub-process sqlite with
>> that, in which case it use an in-memory database.
> 
> Could this potentially cause problems for users of a non-sqlite 
> database?

"Impossible" is a strong word and therefor I'm shy to use it, but it
comes really close to that. To start with: The product "sqlite" is the
only product of the currently supported db engines, that use the :file
property by default.

In theory, a user could have customized another product to use the :file
property for the login parameters, but even after thinking about this
(again) for a few minutes I don't see, how this could make sense (they
are client/server db systems). But even then: my patch changes only one
special case - the user enters the empty string on the read-file-name
prompt - and for every other input everything still is, as it was. And
this one single case, that is altered by my patch, wasn't a resonable
input even after the changes of #23566.

But an even stronger argument is: Prior to the unreleased changes from
#23566 it was in fact impossible (without changing the source file or
effectively replace this part of the implementation with something else
by advice overwrite), to enter the empty string on the read-file-name
prompt (because of the third argument to the read-file-name parameters).

Thanks for taking care.