emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add


From: Tim Cross
Subject: Re: Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)
Date: Tue, 24 Jan 2023 07:12:18 +1100
User-agent: mu4e 1.9.16; emacs 29.0.60

I just wanted to provide some additional information which RMS may find
informative.

Under the hood, ob-sql.el is using the built-in Emacs sql.el library. It
is this library which provides the 'support' for various SQL database
engines. That support has been part of the sql library since it was
added to Emacs in about 1998.

The 'support' is essentially specialised comint based interfaces tweaked
to work with the various SQL database engine command line clients such
as psql for Postgres and sqlplus for Oracle. This involves codes to use
the comint buffer to send commands/regions to the SQL client and read
back the results and run interactive 'repl' like sessions with the
client.

No additional software is installed by either ob-sql.el or sql.el - it
is all just elisp. Any additional software, such as the database client,
must be installed separately by the user (clients on remote machines can
also be used via ssh).

There are no jar files or any other additional bits of software
installed.

There is also some additional support in the form of font-locking which
includes support for different SQL variants i.e. in addition to ANSI
SQL, you can also specify Postgres SQL, Oracle SQL, MS-SQL etc to get
font-locking which supports some of the keyword differences between the
different SQL engines.

Personally, I don't believe any of this contravenes FSF
guidelines. Neither sql.el or ob-sql.el are encouraging use of any
specific database engine. What these libraries do is in fact allow
those who do want to use free software and avenue for interacting with
these systems using free software rather than on-free (similar to Emacs'
WIndows and Mac support).

The software as a service issue is far more difficult to assess when it
comes to databases as the most common architecture with databases is to
have the database on a separate server which is often not local and
where frequently, the user has little or no control over the
software. This has become even more common in recent years due to the
growth in big data and the problem that most individuals and small
groups cannot afford the costs or handle the administrative complexity
associated with hosting databases with large data sets and storage
requirements.

Ihor Radchenko <yantar92@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>   > > Because we already support Orcale, SAP Hana, MSSql and Vertico for 
>> example.
>>
>> Would someone please tell me more concretely what kind of "support"
>> this is? Which GNU package supports them, and how?  
>
> [Jean Luis mentioned M-x sql-* commands in another message. They may
> also be worth discussing, but are not what I meant in the original
> message]
>
> ob-sql is Org mode's feature (part of Emacs) allowing users to execute
> SQL code inline inside Org files:
>
> #+header: :engine sqlite
> #+header: :database ~/.local/share/qutebrowser/history.sqlite
>
> #+begin_src sql
>   SELECT URL FROM History ORDER BY "URL" DESC LIMIT 5 
> #+end_src
>
> #+RESULTS:
> | qute://help/commands.html |
> | qute://help/commands.html |
> | qute://help/              |
> | qute://help               |
> | qute://                   |
>
> Note the :engine argument. It determines which CLI backend is being
> called by Org mode to query the database.
>
> ;; Engines supported:
> ;; - mysql
> ;; - dbi
> ;; - mssql
> ;; - sqsh
> ;; - postgresql (postgres)
> ;; - oracle
> ;; - vertica
> ;; - saphana
>
> Some of these engines are free software and we have no issue supporting
> them. Some are not.
>
>> ... Also, what kind
>> of things are those?  Are they nonfree programs, or are they SaaSS?
>> Some of them I recognize as nonfree programs, but some names I don't
>> recognize at all.
>
> At least, mssql is non-free with no source code available. Same for
> oracle, vertica, and saphana.
>
> I am not sure about SaaSS - even postgresql (free software) may be used
> as a service provider by running it on server the user does not control.
> Probably, I do not fully understand how SaaSS is defined (I did read
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html)
>
> Earlier in the thread, https://github.com/dbcli/athenacli was proposed
> as another CLI to support. Athenacli itself is distributed under BSD-3 -
> free license. However, the CLI is just an interface to Amazon Athena -
> server-side database service.
>
> From my limited understanding, the main purpose of Amazon Athena is
> querying "big data" databases for further analysis, which does not
> constitute SaaSS (AFAIU) - users may not own the "big data" and may not
> have enough resources on their own computers to run the SQL queries that
> utilize machine learning models.
>
>> There are situations where it is acceptable for a GNU package to
>> support its use together with certain nonfree programs.  Mainly when
>> the nonfree program so well known that this support mainly encourage
>> people who already use that nonfree program to start using the GNU
>> package with it, and is unlikely to do the converse.
>>
>> See the GNU Maintainers Guide for more details.
>
> It is hard to define "well known". For me, oracle and mssql databases
> are well-known (just by company name), while saphana and vertica are
> not. But I do not work with SQL and thus lack expertise about what is
> being used in reality. How to judge?
>
>> However, use with a SaaSS system (service as a software substitute) is
>> a different issue (though it has much in common).  I'd like to think
>> about it and ask advisors for advice.  These details can help me start
>> to think about it.
>
> I feel very confused about possible guidelines for SaaSS.
>
> SaaSS does not always require specific CLI tools to be used.
> Consider common HTTP requests or GraphQL that might be employed to
> communicate with SaaSS. Should we stop supporting HTTP requests just
> because they can be used to communicate with SaaSS? Probably no.
> What about something more specific like the ability to query remote
> database provided by SaaSS service? One may just need login/password +
> free sql implementation. What if it is not SELECT query, but INSERT
> query sharing the data with SaaSS? What about the history of SELECT
> queries being associated with the user and the sold to third-party? What
> if external free CLI tool is needed? non-free CLI? There should probably
> be a boundary somewhere, but it is not clear where it should lie.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]