My vote would be to modify ob-sql and change the hard coded values into
a custom variable. Then users can add/remove/modify engine names to suit
their requirements. The default should probably match the product names
supported by sql.el (you could even have multiple entries mapping to the
same product name for backwards compatibility i.e. 'postgres' =>
'postgres', 'postgresql' => 'postgres' etc.). It would also be trivial
to then add new 'products' in the future.

stardiviner <numbch...@gmail.com> writes:

> I'm writing a patch which try to set ~sql-product~ when editing sql src block.
>
> Here is the code:
>
> #+begin_src emacs-lisp
> (defun org-babel-edit-prep:sql (info)
>   "Set `sql-product' in Org edit buffer.
> Set `sql-product' in Org edit buffer according to the
> corresponding :engine source block header argument."
>   (let ((product (cdr (assq :engine (nth 2 info)))))
>     (sql-set-product product)))
> #+end_src
>
> But =ob-sql.el= source code hardcoded ~:engine~ names which some are not 
> matched
> with ~sql-product-alist~ in =sql-mode=. For example =:engine postgresql=, but 
> it's
> ~postgres~ in ~sql-product-alist~.
>
> For now, I have two solutions:
>
> 1. write an adapter function which translate ~:engine~ header argument value 
> into
>    ~sql-product-alist~ product names. This is a safe way, which will not
>    incompatiable with old Org document.
>
> 2. modify source code hardcoded ~:engine~ names (also need to update Org
>    document), this has a minor advantage is *consistance*.
>
> WDYT?
>
> BTW, about writing an adapter function to translate names. I want to hear some
> suggestion about use which method. Writing an hash map or assoc list etc?
>
> Regards


--
Tim Cross

Reply via email to