From attila.lendvai at gmail.com Sat Dec 9 16:46:47 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 9 Dec 2006 17:46:47 +0100 Subject: [pg-devel] cl-rdbms Message-ID: fyi, we've created an alternative for clsql available at: http://common-lisp.net/project/cl-rdbms/ and its first backend is pg! :) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) From attila.lendvai at gmail.com Mon Dec 11 14:51:42 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Mon, 11 Dec 2006 15:51:42 +0100 Subject: [pg-devel] Re: cl-rdbms In-Reply-To: References: Message-ID: > fyi, we've created an alternative for clsql available at: > > http://common-lisp.net/project/cl-rdbms/ i've managed to create a clean darcs repo conversion of pg which is needed to run cl-rdbms and is available at: http://common-lisp.net/cgi-bin/darcsweb/darcsweb.cgi?r=cl-rdbms-pg;a=summary that contains these extra patches at the time of writing: Mon Dec 11 15:47:00 CET 2006 attila.lendvai at gmail.com * FIX: do not flush the network stream in send-packet because it slows down api calls that have multiple send-packet calls in them Mon Dec 11 15:45:44 CET 2006 attila.lendvai at gmail.com * Added int64, float, numeric and boolean binding support by levente.meszaros at gmail.com Mon Dec 11 15:44:37 CET 2006 attila.lendvai at gmail.com * Fix numeric parser for negative numbers by levente.meszaros at gmail.com Mon Dec 11 15:19:22 CET 2006 attila.lendvai at gmail.com tagged Start of darcs repo -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet) From eric.marsden at free.fr Sat Dec 16 13:45:42 2006 From: eric.marsden at free.fr (Eric Marsden) Date: Sat, 16 Dec 2006 14:45:42 +0100 Subject: [pg-devel] Re: cl-rdbms In-Reply-To: (Attila Lendvai's message of "Mon, 11 Dec 2006 15:51:42 +0100") References: Message-ID: <87bqm4osxl.fsf@free.fr> >>>>> "al" == Attila Lendvai 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: -------------- next part -------------- -- Eric Marsden From attila.lendvai at gmail.com Sat Dec 16 14:18:51 2006 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Sat, 16 Dec 2006 15:18:51 +0100 Subject: [pg-devel] Re: cl-rdbms In-Reply-To: <87bqm4osxl.fsf@free.fr> References: <87bqm4osxl.fsf@free.fr> Message-ID: > formats). I haven't yet measured the performance impact of replacing > alist dispatch by EQL specializers. i'm a big fan of muti-method and multiple dispatch, because it is a great way to customize the behaviour of a lib from outside with plugin-like stuff. in this concrete situation i'm not sure about it, but if the measuring doesn't prove a big overhead then i guess it's fine... > 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. i personally don't care about backward compatibility (one can always chose not to get the new changes) and we are developers after all... :) now, darcs makes the management of patches (possibly with incompatible changes in them) a lot easier, but i stop being a darcs advocate... :) -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronst?llet)