Обсуждение: [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