7:38 p.m.
I am currently working on a very simple interface to PostgreSQL using
the libpq library. I have hacked up some code as a module to give me
the C to lisp interface (included in the first attachment).
I am not sure of the "correct" way to pass pointers back to the
user. The user does not actually do anything with the pointers, just
passes them on to other routines. However, it would be useful for
debugging to be able to print the numbers.
An example of this is the `PQconnectdb' function which returns a
connection pointer. This is then passed to the `PQexec' function to
actually perform the commands. I am currently turning the pointers
into integers by setting the lower bit. I am not sure this is the best
way to handle it, it is the simplest and fastest.
A second question is the best way to allocate structures. I would like
them to be normal lisp objects that GC etc., but that can be passed to
C functions. The opaque type looked perfect, except it has a warning
that the objects should never be passed up to lisp.
Thanks for any help or comments on the code,
Sean MacLennan
P.S. The second attachment contains some simple lisp wrappers for the
PQlib code.
#include <pgsql/libpq-fe.h>
#include <emodules.h>
/*
* This is an interface to libpq, the C library interface to
* PostgreSQL. I have attempted a direct 1:1 mapping of C to lisp.
*
* The current version is very incomplete and only implements the
* functions I needed for a very simple calendar program.
*/
#if 0
#define make_conn(conn) make_int((long)conn)
#define make_result(res) make_int((long)res)
#define PGCONN(conn) ((PGconn*)XINT(conn))
#define PGRESULT(res) ((PGresult*)XINT(res))
#else
#define make_conn(conn) ((Lisp_Object)(((long)conn) | Lisp_Type_Int_Bit))
#define make_result(res) ((Lisp_Object)(((long)res) | Lisp_Type_Int_Bit))
#define PGCONN(conn) ((PGconn*)((long)conn & ~Lisp_Type_Int_Bit))
#define PGRESULT(res) ((PGresult*)((long)res & ~Lisp_Type_Int_Bit))
#endif
DEFUN ("PQconnectdb", FPQconnectdb, 1, 1, "", /*
Connect to the PostgreSQL database.
Returns a connection or nil.
*/
(arg_string))
{
PGconn *conn;
CHECK_STRING(arg_string);
conn = PQconnectdb(XSTRING_DATA(arg_string));
return make_conn(conn);
}
DEFUN ("PQfinish", FPQfinish, 1, 1, "", /*
Disconnect from the SQL database.
*/
(conn))
{
CHECK_INT(conn);
PQfinish(PGCONN(conn));
return Qt;
}
DEFUN ("PQexec", FPQexec, 2, 2, "", /*
Exec call.
Returns a results index or nil.
*/
(conn, command))
{
PGresult *res;
CHECK_INT(conn);
CHECK_STRING(command);
res = PQexec(PGCONN(conn), XSTRING_DATA(command));
return make_result(res);
}
DEFUN ("PQclear", FPQclear, 1, 1, "", /*
Free up a result.
*/
(result))
{
CHECK_INT(result);
PQclear(PGRESULT(result));
return Qt;
}
DEFUN ("PQresultStatus", FPQresultStatus, 1, 1, "", /*
Return the result status as an integer.
*/
(result))
{
CHECK_INT(result);
return make_int(PQresultStatus(PGRESULT(result)));
}
DEFUN ("PQresStatus", FPQresStatus, 1, 1, "", /*
Given a result status as an integer, return a status string.
*/
(rc))
{
CHECK_INT(rc);
return build_string(PQresStatus(XINT(rc)));
}
DEFUN ("PQresultErrorMessage", FPQresultErrorMessage, 1, 1, "", /*
Return the result status as a string.
*/
(result))
{
CHECK_INT(result);
return build_string(PQresultErrorMessage(PGRESULT(result)));
}
DEFUN ("PQntuples", FPQntuples, 1, 1, "", /*
Return number of tuples in query result.
*/
(result))
{
CHECK_INT(result);
return make_int(PQntuples(PGRESULT(result)));
}
DEFUN ("PQbinaryTuples", FPQbinaryTuples, 1, 1, "", /*
Return number of binary tuples in query result.
*/
(result))
{
CHECK_INT(result);
return make_int(PQbinaryTuples(PGRESULT(result)));
}
DEFUN ("PQnfields", FPQnfields, 1, 1, "", /*
Return number of fields in query result.
*/
(result))
{
CHECK_INT(result);
return make_int(PQnfields(PGRESULT(result)));
}
DEFUN ("PQgetvalue", FPQgetvalue, 3, 3, "", /*
Get a value result.
*/
(result, tuple, field))
{
CHECK_INT(result);
CHECK_INT(tuple);
CHECK_INT(field);
return build_string(PQgetvalue(PGRESULT(result), XINT(tuple), XINT(field)));
}
void
syms_of_PostgreSQL()
{
DEFSUBR(FPQconnectdb);
DEFSUBR(FPQfinish);
DEFSUBR(FPQexec);
DEFSUBR(FPQclear);
DEFSUBR(FPQresultStatus);
DEFSUBR(FPQresStatus);
DEFSUBR(FPQresultErrorMessage);
DEFSUBR(FPQntuples);
DEFSUBR(FPQbinaryTuples);
DEFSUBR(FPQnfields);
DEFSUBR(FPQgetvalue);
}
void
vars_of_PostgreSQL()
{
}
(defun SQL-connect (db)
(PQconnectdb (concat "dbname=" db)))
(defun SQL-disconnect (conn)
(PQfinish conn))
(defun SQL-insert (conn name values)
(let ((insert (concat "INSERT INTO " name " VALUES ('" (car
values) "'"))
res rc)
(dolist (value (cdr values))
(setq insert (concat insert ",'" value "'")))
(setq insert (concat insert ")"))
(setq res (PQexec conn insert))
(setq rc (PQresultStatus res))
(PQclear res)
(= rc 1)))
(defun SQL-delete (conn name &optional where)
(let ((delete (concat "DELETE FROM " name))
res)
(when where
(setq delete (concat delete " WHERE " where)))
(setq res (PQexec conn delete))
(setq rc (PQresultStatus res))
(PQclear res)
(= rc 1)))
(defun SQL-select (conn what name &optional where order)
(let ((select (concat "SELECT " what " FROM " name))
res tuples fields list sub-list)
(when where
(setq select (concat select " WHERE " where)))
(when order
(setq select (concat select " ORDER BY " order)))
(setq res (PQexec conn select))
(setq rc (PQresultStatus res))
(when (= rc 2)
(setq tuples (PQntuples res)
fields (PQnfields res))
(if (= fields 1)
(dotimes (tuple tuples)
(setq list (cons (PQgetvalue res tuple 0) list)))
(dotimes (tuple tuples)
(setq sub-list nil)
(dotimes (field fields)
(setq sub-list (cons (PQgetvalue res tuple field) sub-list)))
(setq list (cons (nreverse sub-list) list))))
(setq list (nreverse list)))
list))
XEMACS=/home/xemacs/xemacs
SHELL=/bin/sh
RM=rm -f
CC=$(XEMACS)/lib-src/ellcc
CFLAGS=-I. -I$(XEMACS)/src
LD=$(CC) --mode=link
MKINIT=$(CC) --mode=init
SRCS=postgresql.c
OBJS=$(SRCS:.c=.o)
LIBS=-lpq
.c.o:
$(CC) $(CFLAGS) -c $<
MODNAME=PostgreSQL
MODVER=1.0.0
MODTITLE="PostgreSQL loadable module"
all: $(MODNAME).ell
distclean: clean
clean:
$(RM) $(MODNAME).ell $(OBJS) postgresql_i.o postgresql_i.c core
$(MODNAME).ell: $(OBJS) postgresql_i.o $(LIBS)
$(LD) --mod-output=$＠ $(OBJS) postgresql_i.o $(LIBS)
postgresql_i.o: postgresql_i.c
postgresql_i.c: $(SRCS)
ELLMAKEDOC=$(XEMACS)/lib-src/make-docfile $(MKINIT) --mod-output=$＠ \
--mod-name=$(MODNAME) --mod-version=$(MODVER) \
--mod-title=$(MODTITLE) $(SRCS)
9:20 p.m.
On Mon, 2 Apr 2001 at 14:38:40 -0400, Sean MacLennan
<sean.maclennan(a)pika.ca> wrote:
I am currently working on a very simple interface to PostgreSQL
using
the libpq library. I have hacked up some code as a module to give me
the C to lisp interface (included in the first attachment).
Sounds cool!
I am not sure of the "correct" way to pass pointers back to
the
user. The user does not actually do anything with the pointers, just
passes them on to other routines. However, it would be useful for
debugging to be able to print the numbers.
So you want to give the user a handle which the user should not modify,
whose contents are irrelevant to the user, and whose contents are
relevant to the debugging process. In that case, you should probably
create your own data type. I'd do something like this:
------------------------------------------------------------------------
/* Some .h file */
struct pg_result
{
struct lcrecord_header header;
PGresult *res;
};
DECLARE_EXTERNAL_LRECORD (pg_result, struct pg_result);
#define XPG_RESULT(x) XRECORD (x, pg_result, struct pg_result)
#define XSETPG_RESULT(x, p) XSETRECORD (x, p, pg_result)
#define PG_RESULTP(x) RECORDP (x, pg_result)
#define CHECK_PG_RESULT(x) CHECK_RECORD (x, pg_result)
#define CONCHECK_PG_RESULT(x) CONCHECK_RECORD (x, pg_result)
#define XREALPG_RESULT(x) XPG_RESULT(x)->msg
extern Lisp_Object make_pg_result (PGresult *);
------------------------------------------------------------------------
/* Some .c file */
static void
print_pg_result (Lisp_Object obj, Lisp_Object printcharfun, int escapeflag)
{
PGresult *result = XPG_RESULT (obj);
/* Insert code to write result with printcharfun */
}
Lisp_Object
make_pg_result (PGresult *res_ptr)
{
struct pg_result *result;
Lisp_Object lisp_res;
result = alloc_lcrecord_type (struct pg_result, &lrecord_pg_result);
result->res = res_ptr;
XSETPG_RESULT (lisp_res, result);
return lisp_res;
}
DEFINE_EXTERNAL_LRECORD_IMPLEMENTATION ("pg-result", pg_result, 0,
print_pg_result, 0, 0, 0, 0,
struct pg_result);
void
syms_of_whatever_this_is (void)
{
INIT_EXTERNAL_LRECORD_IMPLEMENTATION (pg_result);
...
}
------------------------------------------------------------------------
Now the Lisp programmer will see Lisp objects of type pg-result coming
out of PQexec. You'd have to do something similar for a PGconn. This
isn't too bad as long as you don't have too many types that need to be
treated in such a manner.
A second question is the best way to allocate structures. I would
like
them to be normal lisp objects that GC etc., but that can be passed to
C functions. The opaque type looked perfect, except it has a warning
that the objects should never be passed up to lisp.
Use the same approach as above. I've got some examples of doing this
kind of thing here:
<URL:http://www.ittc.ku.edu/~james/computer/viavoice.html>;. That page
might move soon, since I appear to be getting around to doing something
about my pathetic web site today. I plan to eventually have it here:
<URL:http://www.ittc.ku.edu/~james/xemacs/viavoice.html>;.
--
Jerry James
9:32 p.m.
James,
Thanks, this is exactly what I was looking for. I will try it tonight
at home.
Thanks again,
Sean
12:42 a.m.
Thanks to Jerry James, I have a much cleaner implementation of the
PostgreSQL module (attached below).
Now another question about modules: how do I include libraries
dynamically? Currently I am linking in the pq library statically. This
produces a 116k .ell file.
Sean
5:39 a.m.
>>>> "Sean" == Sean MacLennan
<seanm(a)storm.ca> writes:
Sean> Thanks to Jerry James, I have a much cleaner implementation
Sean> of the PostgreSQL module (attached below).
Um, what, if any relation does this module have to Steve Baur's quite
complete and fairly well-tested implementation in src/postgresql.[hc],
documented in man/lispref/postgresql.texi, in the 21.2.x series? This
may have already been integrated with some downstream implementations
of XEmacs (in particular, Infodock and Turbolinux's packages). You'd
have to ask Steve about that <steve(a)turbolinux.co.jp>. He's not
currently subscribed to xemacs-beta AFAIK.
Also note that in the past some reviewers strongly opposed the use of
implementation-specific idioms at the Lisp level (ie, ODBC or mysql or
postgresql), preferring a generic Emacs interface with "escapes" for
efficient use of variations (a la Perl's generic database interface).
I suggest it would be desirable to think about how modules might make
it easier or harder to implement such a generic interface, and how
much parallelism with other db engines like mysql could be achieved in
the low-level interfaces.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."
1:27 p.m.
Sean MacLennan <sean.maclennan(a)pika.ca> writes:
I am currently working on a very simple interface to PostgreSQL
using the libpq library. I have hacked up some code as a module to
give me the C to lisp interface (included in the first attachment).
A PostgreSQL interface already exists. Have you overlooked it, or do
you intentionally build your own (for whatever reasons)?
#if 0
#define make_conn(conn) make_int((long)conn)
#define make_result(res) make_int((long)res)
#define PGCONN(conn) ((PGconn*)XINT(conn))
#define PGRESULT(res) ((PGresult*)XINT(res))
#else
#define make_conn(conn) ((Lisp_Object)(((long)conn) | Lisp_Type_Int_Bit))
#define make_result(res) ((Lisp_Object)(((long)res) | Lisp_Type_Int_Bit))
#define PGCONN(conn) ((PGconn*)((long)conn & ~Lisp_Type_Int_Bit))
#define PGRESULT(res) ((PGresult*)((long)res & ~Lisp_Type_Int_Bit))
#endif
No, this is not the way to do it. Take a look at
DEFINE_LRECORD_IMPLEMENTATION.
The file ldap.c should be educational because it is fairly simple and
it also wraps some C structures into Lisp objects.
9:51 a.m.
>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> Also note that in the past some
reviewers strongly opposed the use of
SJT> implementation-specific idioms at the Lisp level (ie, ODBC or mysql or
SJT> postgresql), preferring a generic Emacs interface with "escapes" for
SJT> efficient use of variations (a la Perl's generic database interface).
I don't consider ODBC implementation-specific; instead, I consider it
a generic interface, and so more suitable for an application like
xemacs to target.
3:40 p.m.
Martin Buchholz <martin(a)xemacs.org> writes:
>>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> Also note that in the past some reviewers strongly opposed the use of
SJT> implementation-specific idioms at the Lisp level (ie, ODBC or mysql or
SJT> postgresql), preferring a generic Emacs interface with "escapes" for
SJT> efficient use of variations (a la Perl's generic database interface).
I don't consider ODBC implementation-specific; instead, I consider
it a generic interface, and so more suitable for an application like
xemacs to target.
It is a generic interface, but that doesn't mean that XEmacs should
follow it.
ODBC is clumsy, C-oriented, and doesn't support many database-specific
things. It is sometimes accused of being extremely slow, but I won't
go into that.
My point is that XEmacs should define a simple Lispish database API
modeled after prior art (Perl DBI, Python DB), with backends into
implementation-specific stuff, which includes ODBC. Yes, I know that
handling ODBC as an implementation-specific thing sounds insane, but
that's how the world works.
7:14 a.m.
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)arsdigita.com> writes:
Hrvoje> Martin Buchholz <martin(a)xemacs.org> writes:
> >>>>> "SJT" == Stephen J Turnbull
<turnbull(a)sk.tsukuba.ac.jp> writes:
SJT> Also note that in the past some
reviewers strongly opposed the use of
SJT> implementation-specific idioms at the Lisp level (ie, ODBC or mysql or
SJT> postgresql), preferring a generic Emacs interface with "escapes" for
SJT> efficient use of variations (a la Perl's generic database interface).
>
> I don't consider ODBC implementation-specific; instead, I consider
> it a generic interface, and so more suitable for an application like
> xemacs to target.
Hrvoje> It is a generic interface, but that doesn't mean that XEmacs should
Hrvoje> follow it.
Hrvoje> ODBC is clumsy, C-oriented, and doesn't support many database-specific
Hrvoje> things. It is sometimes accused of being extremely slow, but I won't
Hrvoje> go into that.
I've never used ODBC myself, and I trust your judgement.
Hrvoje> My point is that XEmacs should define a simple Lispish database API
Hrvoje> modeled after prior art (Perl DBI, Python DB), with backends into
Hrvoje> implementation-specific stuff, which includes ODBC. Yes, I know that
Hrvoje> handling ODBC as an implementation-specific thing sounds insane, but
Hrvoje> that's how the world works.
Agreed.
8439
days inactive
8449
days old
8 comments
6 participants
participants (6)
-
Hrvoje Niksic -
Jerry James -
Martin Buchholz -
Sean MacLennan -
Sean MacLennan -
Stephen J. Turnbull