[pg-devel] Re: cl-rdbms

[Eric Marsden]

>>>>> "al" == Attila Lendvai <attila.lendvai at gmail.com> writes:

  al> http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-rdbms-pg;a=summary
  al> 
  al> that contains these extra patches at the time of writing:
  al> 
  al> Mon Dec 11 15:47:00 CET 2006  attila.lendvai at gmail.com
  al> * FIX: do not flush the network stream in send-packet because it
  al> slows down api calls that have multiple send-packet calls in them
  al> 
  al> Mon Dec 11 15:44:37 CET 2006  attila.lendvai at gmail.com
  al> * Fix numeric parser for negative numbers by levente.meszaros at gmail.com

  thanks, I have committed these changes.
  
  al> * Added int64, float, numeric and boolean binding support by

  I am thinking of reimplementing all the parsing and serializing code
  in pg-dot-lisp to be more generic. I've attached the current state
  of my work on this. It is based on three generic functions:

(defgeneric parse-value (data type))
(defgeneric serialize-value (value type connection))
(defgeneric generate-random-value (type))

  Functions on PARSE-VALUE replace the dispatch on the *TYPE-PARSERS*
  alist, converting data in the wire format to lisp-level data. This
  finally provides a mechanism for users to extend the parsing code
  when they have custom data types stored in PostgreSQL (eg GIS data
  formats). I haven't yet measured the performance impact of replacing
  alist dispatch by EQL specializers.

  Functions on SERIALIZE-VALUE convert from lisp-level format to wire
  format (either the PostgreSQL FE/BE binary format, or in some cases
  the FE/BE text format). I would like to replace current code for
  binding prepared statement data (which is crufty, incomplete and non
  extensible) with this code, but it will not be a backward-compatible
  change since the argument type specifiers will change. The
  GENERATE-RANDOM-VALUE is intended for improving test coverage by
  running tests with randomly generated data.

  Any comments on this code, and on the degree of pain that would be
  caused by breaking backward compatibility for the prepared statement
  stuff (which only recently started working properly ...) would be
  appreciated.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: parsers.lisp
URL: <https://mailman.common-lisp.net/pipermail/pg-devel/attachments/20061216/4f25bc34/attachment.ksh>
-------------- next part --------------

-- 
Eric Marsden