Thread: [ANN] pg.el v0.2 -- Emacs Lisp interface to PostgreSQL
pg.el is a socket-level interface to PostgreSQL for emacs (text editor extraordinaire). The module is capable of type coercions from a range of SQL types to the equivalent Emacs Lisp type. It currently supports neither crypt or Kerberos authentication, nor large objects. The code (version 0.2) is available under GNU GPL from <URL:http://www.chez.com/emarsden/downloads/pg.el> Changes since last release: * now works with XEmacs (tested with Emacs 19.34 & 20.2, and XEmacs 20.4) * added functions to provide database metainformation (list of databases, of tables, of columns) * arguments to `pg:result' are now :keywords * MULE-resistant* more self-testing code Please note that this is a programmer's API, and doesn't provide any form of user interface. Example: (defun demo () (interactive) (let* ((conn (pg:connect "template1" "postgres" "postgres")) (res (pg:exec conn "SELECT * from scshdemo WHERE a = 42"))) (message "status is %s" (pg:resultres :status)) (message "metadata is %s" (pg:result res :attributes)) (message "data is %s" (pg:resultres :tuples)) (pg:disconnect conn))) -- Eric Marsden It's elephants all the way down
On 21 Jul 1999, Eric Marsden wrote: > pg.el is a socket-level interface to PostgreSQL for emacs (text > editor extraordinaire). The module is capable of type coercions from a > range of SQL types to the equivalent Emacs Lisp type. It currently > supports neither crypt or Kerberos authentication, nor large objects. [snip] > Please note that this is a programmer's API, and doesn't provide any > form of user interface. Example: > > (defun demo () > (interactive) > (let* ((conn (pg:connect "template1" "postgres" "postgres")) > (res (pg:exec conn "SELECT * from scshdemo WHERE a = 42"))) > (message "status is %s" (pg:result res :status)) > (message "metadata is %s" (pg:result res :attributes)) > (message "data is %s" (pg:result res :tuples)) > (pg:disconnect conn))) Hello Eric: I am asking a dumb question here, so please be patient. Does this mean that given pg.el you have to write elisp functions in order to make use of it? Is the "defun demo()" above an example of such a function? If I understand correct, to use pg.el, I would write an elisp function in emacs and then evaluate it. Have I got this right? Hugh Lawson Greensboro, North Carolina hglawson@nr.infi.net
> pg.el is a socket-level interface to PostgreSQL for emacs (text > editor extraordinaire). The module is capable of type coercions from a > range of SQL types to the equivalent Emacs Lisp type. It currently > supports neither crypt or Kerberos authentication, nor large objects. > The code (version 0.2) is available under GNU GPL from > <URL:http://www.chez.com/emarsden/downloads/pg.el> > Please note that this is a programmer's API, and doesn't provide any > form of user interface. Neat stuff! Just curious: 1) it looks lisp-y, but I didn't look very closely; how much does this code resemble that for other lisp packages such as Allegro? 2) you are distributing it under GPL. No problem with that, but if you were amenable to distributing under a BSD-style license we could include it in the main Postgres distribution. Is that a possibility? It would be nice to have the foundation for another language interface for folks to work with. Thanks again for the code. If the url you published is a good long-term reference, then I'll add your introductory mail message to the docs. Regards. - Thomas -- Thomas Lockhart lockhart@alumni.caltech.edu South Pasadena, California
>>>>> "hl" == Hugh Lawson <hglawson@nr.infi.net> writes: hl> I am asking a dumb question here, so please be patient. Does hl> this mean that given pg.el you have to write elispfunctions in hl> order to make use of it? hl> hl> Is the "defun demo()" above an example of such a function? If Ihl> understand correct, to use pg.el, I would write an elisp function in hl> emacs and then evaluate it. Have I got thisright? Hi Hugh, That's right. demo is an example of the type of elisp a programmer would write to access PostgreSQL from Emacs. You can also play around with it interactively: ELISP> (setq conn (pg:connect "template1" "postgres" "postgres")) <struct cl ...> ELISP> (setq res (pg:exec conn "SELECT* from scshdemo WHERE a=42")) <struct cl ...> ELISP> (pg:result res :status) "SELECT" etc I intend to get together with someone else who has written some table browsing stuff for Emacs to produce a browsing interface to PostgreSQL for the end user, but I haven't had time yet. -- Eric Marsden It's elephants all the way down
>>>>> "tl" == Thomas Lockhart <lockhart@alumni.caltech.edu> writes: tl> 1) it looks lisp-y, but I didn't look very closely; how much tl> does this code resemble that for other lisp packagessuch as tl> Allegro? I assume you mean other "lisp implementations such as Allegro Common Lisp"? The answer is that I have also written a Common Lisp version (actually I wrote the CL version first), and a Scheme version (Scheme is another language in the Lisp family), but given that there is no standard interface to sockets in either Common Lisp or Scheme, the code is implementation-specific. tl> 2) you are distributing it under GPL. No problem with that, but tl> if you wereamenable to distributing under a BSD-style license tl> we could include it in the main Postgres distribution. Is thata tl> possibility? It would be nice to have the foundation for another tl> language interface for folks to work with. this may be a little tricky. pg.el will probably be distributed with Emacs in the future, and thus I will have to assign copyright to the FSF. I will talk with rms about that. Does that mean that even for client code which is intended to run completely independently from the backend, it is not possible to mix BSD and GNU GPL code? The Common Lisp and Scheme implementations, however, are under GNU LGPL, and I have no problem releasing them under another licence. tl> Thanks again for the code. If the url you published is a goodtl> long-term reference, then I'll add your introductory mail tl> message to the docs. give me a few days and I'll write a special page for it. Thanks. -- Eric Marsden It's elephants all the way down
> tl> 1) it looks lisp-y, but I didn't look very closely; how much
> tl> does this code resemble that for other lisp packages such as
> tl> Allegro?
> I assume you mean other "lisp implementations such as Allegro Common
> Lisp"? The answer is that I have also written a Common Lisp version
> (actually I wrote the CL version first), and a Scheme version
> (Scheme is another language in the Lisp family), but given that there
> is no standard interface to sockets in either Common Lisp or Scheme,
> the code is implementation-specific.
Would the CL version be available for the Postgres source tree? It
could form a basis for a generic implementation (with, of course, some
socket-specific stuff).
> tl> 2) you are distributing it under GPL. No problem with that, but
> tl> if you were amenable to distributing under a BSD-style license
> tl> we could include it in the main Postgres distribution. Is that a
> tl> possibility? It would be nice to have the foundation for another
> tl> language interface for folks to work with.
> this may be a little tricky. pg.el will probably be distributed with
> Emacs in the future, and thus I will have to assign copyright to the
> FSF. I will talk with rms about that. Does that mean that even for
> client code which is intended to run completely independently from the
> backend, it is not possible to mix BSD and GNU GPL code? The Common
> Lisp and Scheme implementations, however, are under GNU LGPL, and I
> have no problem releasing them under another licence.
The "license mixing" issue has been a source of confusion for
everyone. I think that up until now we have tried to keep everything
BSD-ish, to avoid having misinterpreted the GPL and hence somehow
unintentionally applying it to the rest of our source tree. As I'm
sure you have seen elsewhere, the discussion on this is always long,
convoluted, and inconclusive.
Perhaps your CL version is a more appropriate piece of code to put in
our tree, especially if the licensing for that could be worked out
separately. If the emacs version is available in other "standard
places" then that should be good enough.
> tl> Thanks again for the code. If the url you published is a good
> tl> long-term reference, then I'll add your introductory mail
> tl> message to the docs.
> give me a few days and I'll write a special page for it. Thanks.
If you want to start with this... ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
>>>>> "tl" == Thomas Lockhart <lockhart@alumni.caltech.edu> writes: tl> Would the CL version be available for the Postgres source tree? tl> It could form a basis for a generic implementation(with, of tl> course, some socket-specific stuff). ok, that is probably the best solution. I will have to clean it up a little first, but if I remember correctly I wrote wrappers for the socket code in CLISP, CMUCL and ACL. -- Eric Marsden It's elephants all the way down
> tl> Would the CL version be available for the Postgres source tree?
> tl> It could form a basis for a generic implementation (with, of
> tl> course, some socket-specific stuff).
> ok, that is probably the best solution. I will have to clean it up a
> little first, but if I remember correctly I wrote wrappers for the
> socket code in CLISP, CMUCL and ACL.
Fantastic! I'll be sure it gets in the tree if you post it.
Thanks.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On 21 Jul 1999, Eric Marsden wrote: > Hi Hugh, > > That's right. demo is an example of the type of elisp a programmer > would write to access PostgreSQL from Emacs. You can also play around > with it interactively: > > ELISP> (setq conn (pg:connect "template1" "postgres" "postgres")) > <struct cl ...> > ELISP> (setq res (pg:exec conn "SELECT * from scshdemo WHERE a=42")) > <struct cl ...> > ELISP> (pg:result res :status) > "SELECT" I can't get the hang of doing this. How do you get the ELISP> prompt? And what exactly do you type? I have succeeded at making the example function work properly. Hugh Lawson Greensboro, North Carolina hglawson@nr.infi.net
>>>>> "hl" == Hugh Lawson <hglawson@nr.infi.net> writes: ecm> ELISP> (setq conn (pg:connect "template1" "postgres" "postgres")) ecm> >> <struct cl ...> ecm> ELISP> (setq res(pg:exec conn "SELECT * from scshdemo WHERE a=42")) ecm> >> <struct cl ...> ecm> ELISP> (pg:result res :status) ecm> >> "SELECT" hl> I can't get the hang of doing this. How do you get the ELISP> hl> prompt? And what exactly do you type? hl> hl> I havesucceeded at making the example function work properly. The "ELISP>" prompt is from typing `M-x ielm' in Emacs (I don't think that XEmacs has anything like this: it's an inferior emacs-lisp). You can also type in the sexps using the *scratch* buffer, or using `M-:'. -- Eric Marsden It's elephants all the way down
On 22 Jul 1999, Eric Marsden wrote: > >>>>> "hl" == Hugh Lawson <hglawson@nr.infi.net> writes: > > hl> I can't get the hang of doing this. How do you get the ELISP> > hl> prompt? And what exactly do you type? > hl> > hl> I have succeeded at making the example function work properly. > > The "ELISP>" prompt is from typing `M-x ielm' in Emacs (I don't think > that XEmacs has anything like this: it's an inferior emacs-lisp). You > can also type in the sexps using the *scratch* buffer, or using `M-:'. Thanks Eric, I did what you said, imitated your examples, and it worked. Hugh Lawson Greensboro, North Carolina hglawson@nr.infi.net