bug#31446: 26.1; sql-interactive-mode buffer naming is broken

[Filipp Gunbin <fgunbin@fastmail.fm>]

On 22/05/2018 19:42 +0300, Eli Zaretskii wrote:

>> From: Filipp Gunbin <fgunbin@fastmail.fm>
>> Cc: psainty@orcon.net.nz,  31446@debbugs.gnu.org
>> Date: Tue, 22 May 2018 14:27:27 +0300
>> 
>> > Maybe I'm missing something, but it looks like sql-comint and
>> > sql-product-interactive belong to 2 different families of entry points
>> > in the package.  Some call sql-product-interactive, while the others
>> > call sql-comint.  Isn't that so?
>> 
>> sql-product-interactive is one of the entry points (a generic one).
>> Other entry points are sql-postgres and the like, which specify product.
>
> I said "families" of entry points.  I could be missing something, but
> it looked to me that interactive sql.el commands that call sql-comint
> don't call sql-product-interactive, and vice versa.  If I'm right,
> this problem cannot be solved by using sql-comint.

Here's a quote from sql.el:

;; sql-interactive-mode is used to interact with a SQL interpreter
;; process in a SQLi buffer (usually called `*SQL*').  The SQLi buffer
;; is created by calling a SQL interpreter-specific entry function or
;; sql-product-interactive.  Do *not* call sql-interactive-mode by
;; itself.

That's what I wrote about previously.  If there are some other ways of
entering interactive sql mode, then I'm not aware of them, sorry.

First entry point, sql-product-interactive, calls specific comint
function, say sql-comint-postgres.  These product-specific functions
call sql-comint.

Second entry point(s), sql-postgres and the like, just call
sql-product-interactive.

So it all boils down to sql-comint in the end.

Sorry if I'm wrong somewhere.

>> Well, this patch works for me.
>
> Thanks, I hope Micheal (CC'ed) will look into this when he has time.

Yes, thanks.

Filipp