[PATCH] ob-sql: Add support for Athena

[PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

Hi,

I'm using this patch since a few month that adds support
for AWS Athena.
The only thing that's maybe against adding it is that
`athenacli` (https://github.com/dbcli/athenacli) is not an
official AWS tool but just a Python script.

What's the opinion on this?

Cheers,
  Daniel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ob-sql.el-Add-support-for-Athena.patch --]
[-- Type: text/x-patch, Size: 2150 bytes --]

From ddace051205d20b24c047962ca9d1335bdd90284 Mon Sep 17 00:00:00 2001
From: Daniel Kraus <daniel@kraus.my>
Date: Mon, 16 Jan 2023 11:35:02 +0100
Subject: [PATCH] lisp/ob-sql.el: Add support for Athena

* lisp/ob-sql.el (org-babel-execute:sql): Add support for Athena
---
 lisp/ob-sql.el | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 39a4573a5..640ecb2c0 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -53,14 +53,15 @@
 ;; - rowname-names
 ;;
 ;; Engines supported:
-;; - mysql
+;; - athena
 ;; - dbi
 ;; - mssql
-;; - sqsh
-;; - postgresql (postgres)
+;; - mysql
 ;; - oracle
-;; - vertica
+;; - postgresql (postgres)
 ;; - saphana
+;; - sqsh
+;; - vertica
 ;;
 ;; TODO:
 ;;
@@ -254,6 +255,11 @@ This function is called by `org-babel-execute-src-block'."
                        (org-babel-temp-file "sql-out-")))
 	 (header-delim "")
          (command (cl-case (intern engine)
+                    (athena (format "athenacli %s -e %s %s > %s"
+			            (or cmdline "")
+			            (org-babel-process-file-name in-file)
+                                    database
+			            (org-babel-process-file-name out-file)))
                     (dbi (format "dbish --batch %s < %s | sed '%s' > %s"
 				 (or cmdline "")
 				 (org-babel-process-file-name in-file)
@@ -352,7 +358,7 @@ SET COLSEP '|'
 	(progn (insert-file-contents-literally out-file) (buffer-string)))
       (with-temp-buffer
 	(cond
-	 ((memq (intern engine) '(dbi mysql postgresql postgres saphana sqsh vertica))
+	 ((memq (intern engine) '(athena dbi mysql postgresql postgres saphana sqsh vertica))
 	  ;; Add header row delimiter after column-names header in first line
 	  (cond
 	   (colnames-p
@@ -377,7 +383,7 @@ SET COLSEP '|'
 	      (goto-char (point-max))
 	      (forward-char -1))
 	    (write-file out-file))))
-	(org-table-import out-file (if (string= engine "sqsh") '(4) '(16)))
+	(org-table-import out-file (if (memq (intern engine) '(athena sqsh)) '(4) '(16)))
 	(org-babel-reassemble-table
 	 (mapcar (lambda (x)
 		   (if (string= (car x) header-delim)
-- 
2.39.0

Re: [PATCH] ob-sql: Add support for Athena

[Ihor Radchenko]

Daniel Kraus <daniel@kraus.my> writes:

> I'm using this patch since a few month that adds support
> for AWS Athena.
> The only thing that's maybe against adding it is that
> `athenacli` (https://github.com/dbcli/athenacli) is not an
> official AWS tool but just a Python script.
>
> What's the opinion on this?

Is this something commonly used?

I see two main issues with the idea:
1. I do not like the idea of adding all the possible CLI tools over
   there in ad-hoc manner. It would be cleaner to provide a
   customization to add various cli tools in a defcustom/defvar without
   manually changing the functions.

2. I feel like it will be hard to maintain such unpopular clients. If
   (1) is addressed + good automatic tests are implemented, things may
   be acceptable for inclusion though.

In summary, I am not against the idea of including a new sql cli, but we
should better provide a centralized API to do so and make sure that we
have test coverage, making sure that things are not broken in future,
when the original committer is gone and nobody else is left familiar
with specific obscure SQL client.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Ihor Radchenko <yantar92@posteo.net> writes:

> Daniel Kraus <daniel@kraus.my> writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
>> What's the opinion on this?
>
> Is this something commonly used?

Athena itself is very widely used. But everyone uses either the
AWS Webinterface or connect with JDBC (DBeaver/Datagrip etc) to it.
The Python tool doesn't seem so popular (only 200 GitHub stars),
that's also my main reason for not adding it.


> I see two main issues with the idea:
> 1. I do not like the idea of adding all the possible CLI tools over
>    there in ad-hoc manner. It would be cleaner to provide a
>    customization to add various cli tools in a defcustom/defvar without
>    manually changing the functions.
>
> 2. I feel like it will be hard to maintain such unpopular clients. If
>    (1) is addressed + good automatic tests are implemented, things may
>    be acceptable for inclusion though.
>
> In summary, I am not against the idea of including a new sql cli, but we
> should better provide a centralized API to do so and make sure that we
> have test coverage, making sure that things are not broken in future,
> when the original committer is gone and nobody else is left familiar
> with specific obscure SQL client.

Completely agree.
If I look in `org-babel-execute:sql` `command`
( https://git.savannah.gnu.org/cgit/emacs/org-mode.git/tree/lisp/ob-sql.el#n256 )
I think it would make sense to somehow make all those commands
customizeable and let users add their own commands.
But that's obviously a bit more work. I'll see if I find time for it
in the coming months.

Thanks,
  Daniel

Re: [PATCH] ob-sql: Add support for Athena

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Daniel Kraus <daniel@kraus.my> writes:
>
>> I'm using this patch since a few month that adds support
>> for AWS Athena.
>> The only thing that's maybe against adding it is that
>> `athenacli` (https://github.com/dbcli/athenacli) is not an
>> official AWS tool but just a Python script.
>>
>> What's the opinion on this?
>
> Is this something commonly used?
>
> I see two main issues with the idea:
> 1. I do not like the idea of adding all the possible CLI tools over
>    there in ad-hoc manner. It would be cleaner to provide a
>    customization to add various cli tools in a defcustom/defvar without
>    manually changing the functions.
>
> 2. I feel like it will be hard to maintain such unpopular clients. If
>    (1) is addressed + good automatic tests are implemented, things may
>    be acceptable for inclusion though.
>
> In summary, I am not against the idea of including a new sql cli, but we
> should better provide a centralized API to do so and make sure that we
> have test coverage, making sure that things are not broken in future,
> when the original committer is gone and nobody else is left familiar
> with specific obscure SQL client.

I think you run a high risk of running into GNU policy issues wrt
licensing and free software support given this is a cleint for an AWS
only database. 

Re: [PATCH] ob-sql: Add support for Athena

[Daniel Kraus]

Tim Cross <theophilusx@gmail.com> writes:

> I think you run a high risk of running into GNU policy issues wrt
> licensing and free software support given this is a cleint for an AWS
> only database.

Is it because it's cloud only or because it's proprietary?
Because we already support Orcale, SAP Hana, MSSql and Vertico for example.

Cheers,
  Daniel

Supporting non-free SQL clients in ob-sql (was: [PATCH] ob-sql: Add support for Athena)

[Ihor Radchenko]

Daniel Kraus <daniel@kraus.my> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> I think you run a high risk of running into GNU policy issues wrt
>> licensing and free software support given this is a cleint for an AWS
>> only database.
>
> Is it because it's cloud only or because it's proprietary?

Both. For cloud, see
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
(we can have cloud service support, but only those that are not unjust)

> Because we already support Orcale, SAP Hana, MSSql and Vertico for example.

We probably should not.
Ideally, we need universal SQL cli support and then move all non-free
clients to external packages.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Daniel Kraus <daniel@kraus.my> writes:
>
>> Tim Cross <theophilusx@gmail.com> writes:
>>
>>> I think you run a high risk of running into GNU policy issues wrt
>>> licensing and free software support given this is a cleint for an AWS
>>> only database.
>>
>> Is it because it's cloud only or because it's proprietary?
>
> Both. For cloud, see
> https://www.gnu.org/philosophy/who-does-that-server-really-serve.html
> (we can have cloud service support, but only those that are not unjust)
>
>> Because we already support Orcale, SAP Hana, MSSql and Vertico for example.
>
> We probably should not.
> Ideally, we need universal SQL cli support and then move all non-free
> clients to external packages.

Well, we don't really support those other databases in the same sense as
is bieng proposed here for this AWS db. Those other databases are only
supported in the sense that you can tell sql mode you are using one of
them and you can add the necessary configuration parameters to make a
connnection, but that is it. We don't, for example, provide the Oracle
client in order to use the oracle database. The user has to install the
Oracle client separately.

So, you could likely modify sql-mode to support the ability to pass
necessary parameters to a client which can connect to the AWS database,
but you cannot bundle the client (in this case, the python code you
referenced).

The fact this is also a cloud based database does make the situation
worse as the official FSF and GNU position is that cloud based services
represent a reduction in user freedom because they do not control those
services and cannot see the soruce code - essentially, use of those
services makes you dependent on and to some extent beholding to (in this
case) Amazon. With the other non-free databases, such as Oracle, you can
at least install the database on your own hardware.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 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?  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.

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.

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.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2023-01-23 07:25]:

>   > > 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?

You can find interactive support in `sql' library, functions such as:

M-x sql-oracle 

which supports proprietary Oracle Database:
https://en.wikipedia.org/wiki/Oracle_Database

or 

M-x sql-ms

which description says:

sql-ms is an autoloaded interactive byte-compiled Lisp function in
‘sql.el’.

(sql-ms &optional BUFFER)

Run osql by Microsoft as an inferior process.

> Which GNU package supports them, and how?

Emacs, sql package

> Are they nonfree programs, or are they SaaSS?

They are proprietary programs that may be also SaaSS.


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Ihor Radchenko]

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Tim Cross]

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Would someone please tell me more concretely what kind of "support"
  > > this is?

  > You can find interactive support in `sql' library, functions such as:

  > M-x sql-oracle 

  > which supports proprietary Oracle Database:

This raises two questions.

1. For this purpose, what kind of thing is "the Oracle Database"?
a. A library to link with?
b. A program to run in a subprocess?
c. A server running SaaSS?

2. How does Emacs communicate with that thing?
a. By function calls within a process?
b. Via shared memory?
c. Via a pty or pipe?
d. Via sockets?

The answers are crucial for thinking about what our moral ideas and
policies say about this case.

  > (sql-ms &optional BUFFER)

  > Run osql by Microsoft as an inferior process.

This suggests an answer to the first question.
More precisely, it suggests that the answer is b
_at least some of the time_.

  > > Are they nonfree programs, or are they SaaSS?

  > They are proprietary programs that may be also SaaSS.

Does the Emacs support offer to talk with a remote web server?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Tim Cross]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Would someone please tell me more concretely what kind of "support"
>   > > this is?
>
>   > You can find interactive support in `sql' library, functions such as:
>
>   > M-x sql-oracle 
>
>   > which supports proprietary Oracle Database:
>
> This raises two questions.
>
> 1. For this purpose, what kind of thing is "the Oracle Database"?
> a. A library to link with?
> b. A program to run in a subprocess?
> c. A server running SaaSS?
>

None of the above!

Richard,

to be very clear, ob-sql is not adding any NEW interface to any external
program. It is just using the Emacs built-in SQL library (Elisp), which
has been part of Emacs for a long time (I was using it in late 90s to
work with Oracle RDMS). It is this library that provides the 'support'
for things like Oracle's RDMS. If you want more specific information,
ask on emacs-devel. Org mode is just using this built-in library.

The Oracle database is simply a relational database management system in
the same way as Postgres, MySQL, Ingris, MS-Sql server etc. All of these
have a CLI client and support connections via JDBC. The sql.el library
provides specialised comint based interfaces which run the CLI to
communicate with the RDMS. The closest of your 3 choices is b, as the
build-in Emacs sql library executes the RDMS CLI in a sub-process comint
buffer.

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

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2023-01-25 07:32]:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>   > > Would someone please tell me more concretely what kind of "support"
>   > > this is?
> 
>   > You can find interactive support in `sql' library, functions such as:
> 
>   > M-x sql-oracle 
> 
>   > which supports proprietary Oracle Database:
> 
> This raises two questions.
> 
> 1. For this purpose, what kind of thing is "the Oracle Database"?
> a. A library to link with?
> b. A program to run in a subprocess?

It is program that runs in a subprocess.

> c. A server running SaaSS?

Theoretically it could be as access may be network based. 

But according to my knowledge this product is proprietary and may be
downloaded and run on users' computer or network computers.

> 2. How does Emacs communicate with that thing?
> a. By function calls within a process?

Yes.

> b. Via shared memory?
> c. Via a pty or pipe?
> d. Via sockets?

By invoking proprietary program named "sqlplus" which function is
defined in library "sql.el" and by using comint-mode

(defcustom sql-oracle-program "sqlplus"
  "Command to start sqlplus by Oracle.

Starts `sql-interactive-mode' after doing some setup.

On Windows, \"sqlplus\" usually starts the sqlplus \"GUI\".  In order
to start the sqlplus console, use \"plus33\" or something similar.
You will find the file in your Orant\\bin directory."
  :type 'file)


(comint-mode)

Major mode for interacting with an inferior interpreter.
Interpreter name is same as buffer name, sans the asterisks.
Return at end of buffer sends line as input.
Return not at end copies rest of line to end and sends it.
Setting variable ‘comint-eol-on-send’ means jump to the end of the line
before submitting new input.

This mode is customized to create major modes such as Inferior Lisp
mode, Shell mode, etc.  This can be done by setting the hoo



In my opinion Emacs should not be invoking proprietary programs, and
distributing sql.el with Emacs opposes the principle of not
recommending proprietary software.

By having functions to run proprietary software from within Emacs we
are advertising proprietary software.


--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> to be very clear, ob-sql is not adding any NEW interface to any external
> program. It is just using the Emacs built-in SQL library (Elisp), which
> has been part of Emacs for a long time (I was using it in late 90s to
> work with Oracle RDMS). It is this library that provides the 'support'
> for things like Oracle's RDMS. If you want more specific information,
> ask on emacs-devel. Org mode is just using this built-in library.

This is wrong.
`org-babel-execute:sql' directly calls the CLI executable via `process-file'.

That said, the discussion about sql.el is also relevant wrt non-free SQL
client support. It will be helpful to clarify what is morally acceptable
for all the scenarios, not just for Org's use-case.

> The Oracle database is simply a relational database management system in
> the same way as Postgres, MySQL, Ingris, MS-Sql server etc. All of these
> have a CLI client and support connections via JDBC. The sql.el library
> provides specialised comint based interfaces which run the CLI to
> communicate with the RDMS. The closest of your 3 choices is b, as the
> build-in Emacs sql library executes the RDMS CLI in a sub-process comint
> buffer.

Org does not use this comint interface yet. We may in future though, for
sessions:

(defun org-babel-prep-session:sql (_session _params)
  "Raise an error because Sql sessions aren't implemented."
  (error "SQL sessions not yet implemented"))

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> to be very clear, ob-sql is not adding any NEW interface to any external
>> program. It is just using the Emacs built-in SQL library (Elisp), which
>> has been part of Emacs for a long time (I was using it in late 90s to
>> work with Oracle RDMS). It is this library that provides the 'support'
>> for things like Oracle's RDMS. If you want more specific information,
>> ask on emacs-devel. Org mode is just using this built-in library.
>
> This is wrong.
> `org-babel-execute:sql' directly calls the CLI executable via `process-file'.
>
> That said, the discussion about sql.el is also relevant wrt non-free SQL
> client support. It will be helpful to clarify what is morally acceptable
> for all the scenarios, not just for Org's use-case.
>
>> The Oracle database is simply a relational database management system in
>> the same way as Postgres, MySQL, Ingris, MS-Sql server etc. All of these
>> have a CLI client and support connections via JDBC. The sql.el library
>> provides specialised comint based interfaces which run the CLI to
>> communicate with the RDMS. The closest of your 3 choices is b, as the
>> build-in Emacs sql library executes the RDMS CLI in a sub-process comint
>> buffer.
>
> Org does not use this comint interface yet. We may in future though, for
> sessions:
>
> (defun org-babel-prep-session:sql (_session _params)
>   "Raise an error because Sql sessions aren't implemented."
>   (error "SQL sessions not yet implemented"))

OK, thanks the for correction. I was confused because the set of
supported RDBMS is the same as those supported by sql.el and the
connection credentials uses the same variable name
i.e. sql-connection-alist.

However, I gues the point remains, sql.el and ob-sql.el support a number
of non-free RDMS and I think this is fine given that

1. There is no encouragement, implicit or explicit, to use a non-free
database
2. Provided support provides a way to interact with these non-free RDMS using
free software.
3. There is no requirement to install non-free software to use
ob-sql.el. The software is fully functional using a free RDMS like
postgres.

For maintenance reasons and to add session support, I would suggest that
using sql.el instead of re-inventing this wheel would be a better
outcome. I've used sql.el for years and it works extremely well and I
don't htink it would be too hard to integrate into ob-sql.

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

[Ihor Radchenko]

Tim Cross <theophilusx@gmail.com> writes:

> 3. There is no requirement to install non-free software to use
> ob-sql.el. The software is fully functional using a free RDMS like
> postgres.

Yes, but there is requirement to install in order to use ob-sql.el
__with :engine set to non-free option__.

So, I can envision that someone who decided to use ob-sql.el and
considering between free and non-free engine may prefer non-free one. Of
course, it is not very strong argument, but the boundaries are fuzzy in
this area.

> For maintenance reasons and to add session support, I would suggest that
> using sql.el instead of re-inventing this wheel would be a better
> outcome. I've used sql.el for years and it works extremely well and I
> don't htink it would be too hard to integrate into ob-sql.

Sure. That's what we usually do - just use whatever REPL is available
for a given ob-* language. Just a question of someone sending a patch.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Tim Cross]

Ihor Radchenko <yantar92@posteo.net> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>
>> 3. There is no requirement to install non-free software to use
>> ob-sql.el. The software is fully functional using a free RDMS like
>> postgres.
>
> Yes, but there is requirement to install in order to use ob-sql.el
> __with :engine set to non-free option__.
>
> So, I can envision that someone who decided to use ob-sql.el and
> considering between free and non-free engine may prefer non-free one. Of
> course, it is not very strong argument, but the boundaries are fuzzy in
> this area.
>

in the same way someone could choose to run emacs on MS Windows. This
doesn't mean emacs encourages people to use MS Windows. Rather it means
that people who are restricted to MS Windows can at least use a free
editor on that platform. In a similar manner, people who are restricted
to working with a non-free database can access it using free software. I
think this is particularly relevant given the growth in large databases
where users are unable to use a free database or run it locally simply
because of the size of the data and the resource requirements and
administrative complexity involved. 

>> For maintenance reasons and to add session support, I would suggest that
>> using sql.el instead of re-inventing this wheel would be a better
>> outcome. I've used sql.el for years and it works extremely well and I
>> don't htink it would be too hard to integrate into ob-sql.
>
> Sure. That's what we usually do - just use whatever REPL is available
> for a given ob-* language. Just a question of someone sending a patch.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

Thanks.

Based on our general policies, it is ok to do this.  It is ok for
Postgres because that is free software.  It is ok for Oracle because
that is widely known.

Ihor Radchenko <yantar92@posteo.net> wrote:

  > 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.

I have never heard of saphana or vertica, which suggests that maybe
this is an issue.  However, I don't know the database field, so I
am the wrong one to judge.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > 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.

For sure, it CAN be used that way.  If a Lisp package is designed to
work with a subprocess, a user can certainly rig it to talk with a
remote server.  It is the nature of free software that people can
customize it, even so as to do something foolish with it.  When a user
does this, it's per responsibility, not ours.

We should not distribute specific support or recommendations to use
the Lisp package in that particular way.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Supporting non-free SQL clients in ob-sql

[Loris Bennett]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > 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.
>
> Thanks.
>
> Based on our general policies, it is ok to do this.  It is ok for
> Postgres because that is free software.  It is ok for Oracle because
> that is widely known.
>
> Ihor Radchenko <yantar92@posteo.net> wrote:
>
>   > 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.
>
> I have never heard of saphana or vertica, which suggests that maybe
> this is an issue.  However, I don't know the database field, so I
> am the wrong one to judge.

I assume that 'saphana' actually refers to 'SAP HANA'[1], which is an
in-memory RDMS produced by SAP, the large German software company.  I
think this product may well qualify as being 'well-known', at least in
the field of enterprise software.

Cheers,

Loris

Footnotes:
[1]  https://en.wikipedia.org/wiki/SAP_HANA

-- 
This signature is currently under constuction.

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

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

> Ihor Radchenko <yantar92@posteo.net> wrote:
>
>   > 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.
>
> I have never heard of saphana or vertica, which suggests that maybe
> this is an issue.  However, I don't know the database field, so I
> am the wrong one to judge.

Would it then make sense to note the reasons why we support one or
another non-free software in a separate file like etc/NON-FREE-SUPPORT?
Non-free software popular now may not be popular in future, and thus it
will become not ethical to support it then.

Also, what about Emacs supporting MS DOS and old versions of Windows? Do
they still qualify as popular software?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Supporting non-free SQL clients in ob-sql

[Heinz Tuechler]

Ihor Radchenko wrote/hat geschrieben on/am 26.01.2023 11:22:
> Richard Stallman <rms@gnu.org> writes:
>
>> Ihor Radchenko <yantar92@posteo.net> wrote:
>>
>>   > 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.
>>
>> I have never heard of saphana or vertica, which suggests that maybe
>> this is an issue.  However, I don't know the database field, so I
>> am the wrong one to judge.
>
> Would it then make sense to note the reasons why we support one or
> another non-free software in a separate file like etc/NON-FREE-SUPPORT?
> Non-free software popular now may not be popular in future, and thus it
> will become not ethical to support it then.
>
> Also, what about Emacs supporting MS DOS and old versions of Windows? Do
> they still qualify as popular software?
>
Microsoft would probably appreciate, if only the latest version were
supported by free software.
best regards, Heinz

Re: Supporting non-free SQL clients in ob-sql

[Ihor Radchenko]

Heinz Tuechler <tuechler@gmx.at> writes:

>> Also, what about Emacs supporting MS DOS and old versions of Windows? Do
>> they still qualify as popular software?
>>
> Microsoft would probably appreciate, if only the latest version were
> supported by free software.
> best regards, Heinz

Are you implying that dropping support of obsolete non-free software
will encourage users to upgrade to newer versions of the same non-free
software?

If so, I disagree. It might equally encourage users to switch to newer
and also free equivalent. Unless there is no free equivalent, which is
not true for Windows or MS DOS, AFAIK.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Supporting non-free SQL clients in ob-sql

[Heinz Tuechler]

Ihor Radchenko wrote/hat geschrieben on/am 26.01.2023 12:14:
> Heinz Tuechler <tuechler@gmx.at> writes:
>
>>> Also, what about Emacs supporting MS DOS and old versions of Windows? Do
>>> they still qualify as popular software?
>>>
>> Microsoft would probably appreciate, if only the latest version were
>> supported by free software.
>> best regards, Heinz
>
> Are you implying that dropping support of obsolete non-free software
> will encourage users to upgrade to newer versions of the same non-free
> software?
Yes
>
> If so, I disagree. It might equally encourage users to switch to newer
> and also free equivalent.
You maybe right

> Unless there is no free equivalent, which is
> not true for Windows or MS DOS, AFAIK.
>

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 1. For this purpose, what kind of thing is "the Oracle Database"?
  > > a. A library to link with?
  > > b. A program to run in a subprocess?
  > > c. A server running SaaSS?

  > None of the above!

I found that reply tantalizing but not helpful.
Fortunately, others have given helpful replies,
from which I could see there is no ethical problem in
using sql.el to run the Oracle data base software.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Would it then make sense to note the reasons why we support one or
  > another non-free software in a separate file like etc/NON-FREE-SUPPORT?

I think it is a good idea to document the reasoning for these
decision.  But I think it does not necessarily have to be centralized
in one file for all of Emacs.  Another alternative, also natural,
would be to describe these decisions with the code that implements the
support.

  > Also, what about Emacs supporting MS DOS and old versions of Windows? Do
  > they still qualify as popular software?

There is no need to include version numbers when we judge whether a
program is well known.  People are far more likely to think about a
program name than about its various version numbers.

If a program was once well known, but its use is dwindling, it's not
something we have to worry about informing people about.  More people
will have heard of it in the past, than will want to switch to it now.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > However, I gues the point remains, sql.el and ob-sql.el support a number
  > of non-free RDMS

Can someone post a verified list of which of them are non-free?
Someone posted a list of a few, which I cannot find now in my saved
inboxes, but I think it included oracle, mysql, vertica? and a fourth
one else (what was it?).

Does sql.el handle any other nonfree ones aside from those?

   > and I think this is fine given that

That is something we should double-check in accord with the stated
policy.  But first we need to know which ones to check.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > This raises two questions.
  > > 
  > > 1. For this purpose, what kind of thing is "the Oracle Database"?
  > > a. A library to link with?
  > > b. A program to run in a subprocess?

  > It is program that runs in a subprocess.

  > > c. A server running SaaSS?

  > Theoretically it could be as access may be network based. 

  > But according to my knowledge this product is proprietary and may be
  > downloaded and run on users' computer or network computers.

Any nonfree program that users can install to run in a subprocess,
they can easily arrange to communicate with through sockets over the
net.  Thus, supporting a case of (b) implies supporting also the
scenarion (c).

So, if our rules say that (b) is ok in a certain case, we need not worry
separately about (c).

  > > 2. How does Emacs communicate with that thing?
  > > a. By function calls within a process?

  > Yes.

Based on the details you gave, I think we are miscommunicating.
You're saying that a Lisp program communicates with the Oracle
database through calls to other Lisp packages -- but that doesn't
address this question.  Those other Lisp packages are free
and running inside Emacs.

This question is how Emacs communicates with the Oracle database
program.

  > (defcustom sql-oracle-program "sqlplus"
  >   "Command to start sqlplus by Oracle.

If it uses comint mode, it is talking with that program
through a pty or pipe.  So the answer is c.

  > > b. Via shared memory?
  > > c. Via a pty or pipe?
  > > d. Via sockets?

But this text from a doc string makes me concerned

  > On Windows, \"sqlplus\" usually starts the sqlplus \"GUI\".  In order
  > to start the sqlplus console, use \"plus33\" or something similar.
  > You will find the file in your Orant\\bin directory."

because it isn't clear.  It is sketchy.  An expert on running that
database on Windows might understand it, but someone who only knows
about Emacs can't even try.

How does sql.el communicate with sqlplus on Windows?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > Would it then make sense to note the reasons why we support one or
>   > another non-free software in a separate file like etc/NON-FREE-SUPPORT?
>
> I think it is a good idea to document the reasoning for these
> decision.  But I think it does not necessarily have to be centralized
> in one file for all of Emacs.  Another alternative, also natural,
> would be to describe these decisions with the code that implements the
> support.

Will file header be a good place?

Note that there is little point adding the reasons behind supporting
non-free software if they cannot be easily found. Ideally, it should be
a standard place documented as code convention. Then, people can
consistently check the reasons (or lack of) behind each individual
non-free software support decision.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > However, I gues the point remains, sql.el and ob-sql.el support a number
>   > of non-free RDMS
>
> Can someone post a verified list of which of them are non-free?
> Someone posted a list of a few, which I cannot find now in my saved
> inboxes, but I think it included oracle, mysql, vertica? and a fourth
> one else (what was it?).
>
> Does sql.el handle any other nonfree ones aside from those?

Note that we are talking about sql.el and also about ob-sql.el, which
are different libraries.

ob-sql.el supports the following non-free SQL implementations:
- mssql (https://en.wikipedia.org/wiki/Microsoft_SQL_Server)
- Oracle (https://en.wikipedia.org/wiki/Oracle_Database)
- Vertica (https://en.wikipedia.org/wiki/Vertica)
- saphana (https://en.wikipedia.org/wiki/SAP_HANA)

sql.el supports the following non-free SQL implementations:
- Oracle (https://en.wikipedia.org/wiki/Oracle_Database)
- SOLID SQL (https://en.wikipedia.org/wiki/SolidDB)
- Sybase (acquired by SAP, see sapphana; https://en.wikipedia.org/wiki/Sybase)
- Informix (https://en.wikipedia.org/wiki/IBM_Informix)
- Ingress (https://en.wikipedia.org/wiki/Ingres_(database))
- mssql (https://en.wikipedia.org/wiki/Microsoft_SQL_Server)
- Interbase (https://en.wikipedia.org/wiki/InterBase)
- DB2 (https://en.wikipedia.org/wiki/IBM_Db2)
- linter (https://en.wikipedia.org/wiki/Linter_SQL_RDBMS)
- Vertica (https://en.wikipedia.org/wiki/Vertica)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I think it is a good idea to document the reasoning for these
  > > decision.  But I think it does not necessarily have to be centralized
  > > in one file for all of Emacs.  Another alternative, also natural,
  > > would be to describe these decisions with the code that implements the
  > > support.

  > Will file header be a good place?

It's a reasonable candidate.

  > Note that there is little point adding the reasons behind supporting
  > non-free software if they cannot be easily found. Ideally, it should be
  > a standard place documented as code convention. Then, people can
  > consistently check the reasons (or lack of) behind each individual
  > non-free software support decision.

That is a valid point.

Sorry for the delay.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

  > > 3. There is no requirement to install non-free software to use
  > > ob-sql.el. The software is fully functional using a free RDMS like
  > > postgres.

  > Yes, but there is requirement to install in order to use ob-sql.el
  > __with :engine set to non-free option__.

Do you mean, "to use ob-sql.el with nonfree program Foo, there is a
requirement to install Foo"?  I think so.

That's true, but it's not a problem.  That's not what we mean when we
say "a requirement to install nonfree software."

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)