From matt.lamari at gmail.com Thu Nov 1 23:00:27 2007 From: matt.lamari at gmail.com (Matthew Lamari) Date: Thu, 1 Nov 2007 18:00:27 -0500 Subject: [postmodern-devel] Capital/mixed-case table/column names? Message-ID: This question may betray a limited understanding of Postmodern or PostGres; but. . . . If possible, how can Postmodern be used to generate queries that can interact with capitalized/mixed-case table and column names? It appears that in postgres, unless double-quoted, a string is converted to lowercase (as with lisp with uppercase). String literals are single-quoted to SQL literals, not double-quoted as appears required for names. Postgres appears to lowercase even symbols containing capitals (e.g. |AbCd|) If no mechanism for mixed-case exists, would the use of mixed-case symbols be an appropriate change to make to PostGres? Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From marijnh at gmail.com Tue Nov 6 07:53:53 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Tue, 6 Nov 2007 09:53:53 +0200 Subject: [postmodern-devel] Capital/mixed-case table/column names? In-Reply-To: References: Message-ID: Hello Matthew, As I understand it, Postgresql converts all function, table, and field names to lowercase. Thus, the case in which Postmodern sends them would be irrelevant. If you have a case where this does make a difference, let me know. Cheers, Marijn From attila.lendvai at gmail.com Thu Nov 8 12:28:07 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 8 Nov 2007 13:28:07 +0100 Subject: [postmodern-devel] development plans for discussion Message-ID: hi! i have two changes planned: 1) use babel for string encoding/decoding ( http://common-lisp.net/~loliveira/soc07/babel/ ). the rationale is that it's a very nice cross platform unicode lib which is also very fast. Marijn, i hope you will not take it as offense! i know trivial-utf8 is your work, but i hope the speed and the de facto standardness of babel compensates. (Luis will give babel more publicity in the next weeks, but it's available for months now and i'm using it without problems). 2) use iolib for the socket code. i would like to do that because we are experiencing problems when dealing with sockets on sbcl when the system is under heavy load. another reason is that iolib is another nice piece of code, although its also more heavyweight then usocket and also posix-only (currently). i know you prefer simple libs, just like with ironclad/md5, but we need stability and this seems to be the simplest way to achive it. what do you think of these changes? -- attila From marijnh at gmail.com Thu Nov 8 17:57:31 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 8 Nov 2007 19:57:31 +0200 Subject: [postmodern-devel] development plans for discussion In-Reply-To: References: Message-ID: Hi Attila, About the encoding -- don't worry about ditching trivial-utf-8, if there is a faster and more general alternative that's cool. I don't see any functionality for writing directly to a stream in it though, but maybe I didn't look hard enough. Perform some benchmarks to prove that babel actually speeds things up before building a patch. I didn't know iolib. It looks cool -- but I'm not okay with making postmodern posix-only. If you can find a way to make the socket library 'pluggable', that would be cool... but then we're writing a wrapper around socket wrapper libraries, which is a bit screwy. Have you looked deeply in the problems you're having with usocket? Might they be fixed by patching usocket? Cheers, Marijn From attila.lendvai at gmail.com Thu Nov 8 21:00:16 2007 From: attila.lendvai at gmail.com (Attila Lendvai) Date: Thu, 8 Nov 2007 22:00:16 +0100 Subject: [postmodern-devel] development plans for discussion In-Reply-To: References: Message-ID: > About the encoding -- don't worry about ditching trivial-utf-8, if > there is a faster and more general alternative that's cool. I don't > see any functionality for writing directly to a stream in it though, > but maybe I didn't look hard enough. Perform some benchmarks to prove > that babel actually speeds things up before building a patch. ok. i'm waiting for Luis to push some of his changes, and after that i'll add buffered stream writing capabilities if it's not among the new patches. > I didn't know iolib. It looks cool -- but I'm not okay with making > postmodern posix-only. If you can find a way to make the socket > library 'pluggable', that would be cool... but then we're writing a > wrapper around socket wrapper libraries, which is a bit screwy. Have > you looked deeply in the problems you're having with usocket? Might > they be fixed by patching usocket? the problem is with sb-bsd-sockets. but even if it were working fine then usocket would be missing api for timeouts. my problem is that sometimes the connection is dropped (no idea why, there's no error in the postgres log), but when it happens in the wrong phase then the CL:CLOSE call hangs in TRY-TO-SYNC forever. my current fix is a local kludge patch that uses sbcl's WITH-TIMEOUT directly. i'll try to make iolib compile-time pluggable and if it's not too kludgy then i'll record it and report back. happy hacking, -- attila From holtzermann17 at gmail.com Wed Nov 14 22:13:15 2007 From: holtzermann17 at gmail.com (Joe Corneli) Date: Wed, 14 Nov 2007 16:13:15 -0600 Subject: [postmodern-devel] connecting Message-ID: I can run psql from the shell -- % psql Welcome to psql 7.4.17, the PostgreSQL interactive terminal. Type: \copyright for distribution terms \h for help with SQL commands \? for help on internal slash commands \g or terminate with semicolon to execute query \q to quit joe=# but trying to connect to PostgreSQL with Postmodern currently fails: CL-USER> (connect-toplevel "joe" "joe" "" "localhost") Backtrace: 0: (USOCKET::HANDLE-CONDITION # #) 1: (USOCKET:SOCKET-CONNECT "localhost" 5432) 2: (CL-POSTGRES::INITIATE-CONNECTION #) 3: (CL-POSTGRES:OPEN-DATABASE "joe" "joe" "" "localhost" 5432) 4: (CONNECT-TOPLEVEL "joe" "joe" "" "localhost") 5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (CONNECT-TOPLEVEL "joe" "joe" "" "localhost") #) Can you give me any ideas on how to get this connection working? This is a fresh install of Postmodern, but I am using some old ASDF files for dependences, do you think that could be the problem? From xach at xach.com Wed Nov 14 22:14:37 2007 From: xach at xach.com (Zach Beane) Date: Wed, 14 Nov 2007 17:14:37 -0500 Subject: [postmodern-devel] connecting In-Reply-To: References: Message-ID: <20071114221437.GN1985@xach.com> On Wed, Nov 14, 2007 at 04:13:15PM -0600, Joe Corneli wrote: > I can run psql from the shell -- > > % psql > Welcome to psql 7.4.17, the PostgreSQL interactive terminal. > > Type: \copyright for distribution terms > \h for help with SQL commands > \? for help on internal slash commands > \g or terminate with semicolon to execute query > \q to quit > > joe=# > > but trying to connect to PostgreSQL with Postmodern currently fails: The psql client will use the Unix socket if available. Is your postgres configured to also listen via TCP? Zach From holtzermann17 at gmail.com Wed Nov 14 22:49:47 2007 From: holtzermann17 at gmail.com (Joe Corneli) Date: Wed, 14 Nov 2007 16:49:47 -0600 Subject: [postmodern-devel] connecting In-Reply-To: <20071114221437.GN1985@xach.com> References: <20071114221437.GN1985@xach.com> Message-ID: Ah, no, it wasn't -- now it is. And that works. On 11/14/07, Zach Beane wrote: > On Wed, Nov 14, 2007 at 04:13:15PM -0600, Joe Corneli wrote: > > I can run psql from the shell -- > > > > % psql > > Welcome to psql 7.4.17, the PostgreSQL interactive terminal. > > > > Type: \copyright for distribution terms > > \h for help with SQL commands > > \? for help on internal slash commands > > \g or terminate with semicolon to execute query > > \q to quit > > > > joe=# > > > > but trying to connect to PostgreSQL with Postmodern currently fails: > > The psql client will use the Unix socket if available. Is your > postgres configured to also listen via TCP? > > Zach > _______________________________________________ > postmodern-devel mailing list > postmodern-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel > From holtzermann17 at gmail.com Thu Nov 15 00:34:31 2007 From: holtzermann17 at gmail.com (Joe Corneli) Date: Wed, 14 Nov 2007 18:34:31 -0600 Subject: [postmodern-devel] views Message-ID: So, Postmodern doesn't seem to have very minimal support for views (just `list-views' and `view-exists-p'), but I assume I can still work with them? Any tips on that? From xach at xach.com Thu Nov 15 00:38:49 2007 From: xach at xach.com (Zach Beane) Date: Wed, 14 Nov 2007 19:38:49 -0500 Subject: [postmodern-devel] views In-Reply-To: References: Message-ID: <20071115003849.GO1985@xach.com> On Wed, Nov 14, 2007 at 06:34:31PM -0600, Joe Corneli wrote: > So, Postmodern doesn't seem to have very minimal support for views > (just `list-views' and `view-exists-p'), but I assume I can still work > with them? Any tips on that? I think you can treat them just like tables. Zach From marijnh at gmail.com Thu Nov 15 17:54:29 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Thu, 15 Nov 2007 18:54:29 +0100 Subject: [postmodern-devel] views In-Reply-To: References: Message-ID: Hey Joe, Views are indeed something that I didn't pay much attention to -- I'm not really in the habit of making much use of them myself. As Zach said, they can be treated as tables when selecting, but S-SQL does not have :create-view or :drop-view operators defined, so to make them convenient to work with you'd want to either add that, or do all your creating/dropping directly from the SQL prompt. (If you end up adding them, I'd be happy to apply your patch to the repository). Cheers, Marijn From info at jensteich.de Sat Nov 17 18:10:43 2007 From: info at jensteich.de (Jens Teich) Date: Sat, 17 Nov 2007 19:10:43 +0100 Subject: [postmodern-devel] Warnings from bordeaux-threads Message-ID: <017f01c82945$2f222bf0$6502a8c0@JensSony> I have a problem with warnings from bordeaux-threads. These warnings are no problem when I load manually on Lispworks and SBCL. But when I try to deliver a stand-alone application on Lispworks the delivery process stops at these warnings. I reported the problem to bordeaux-threads mailinglist. They are as follows: | ; Loading fasl file d:\Projekte\Lisp\bordeaux-threads\src\bordeaux-threads.ofasl | ; Loading fasl file d:\Projekte\Lisp\bordeaux-threads\src\lispworks.ofasl | Warning: (METHOD | MAKE-THREAD | (T)) being redefined in d:\Projekte\Lisp\bordeaux- | threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- | threads\src\bordeaux-threads.lisp). | Warning: (METHOD | MAKE-LOCK | NIL) being redefined in d:\Projekte\Lisp\bordeaux- | threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- | threads\src\bordeaux-threads.lisp). | Warning: (DEFMACRO WITH-LOCK-HELD) being redefined in d:\Projekte\Lisp\bordeaux- | threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- | threads\src\bordeaux-threads.lisp). | Warning: (METHOD | THREAD-YIELD | NIL) being redefined in d:\Projekte\Lisp\bordeaux- | threads\src\lispworks.lisp (previously in d:\Projekte\Lisp\bordeaux- | threads\src\bordeaux-threads.lisp). Is there a way for postmodern to load without bordeux-threads? I think on Lispworks I don't need this. I tried the following (changed t and nil) | ;; Change this to manually turn threading support on or off. | (defparameter *threads* #+(or allegro armedbear cmu corman (and digitool ccl-5.1) | ecl lispworks openmcl sbcl) nil | #-(or allegro armedbear cmu corman (and digitool ccl-5.1) | ecl lispworks openmcl sbcl) t) but there is some resistance: | Loading fasl file d:\Projekte\Lisp\postmodern-1.02\postmodern\connect.ofasl | | Error: Package BORDEAUX-THREADS not found. | 1 Get another package name. | ... Jens From marijnh at gmail.com Sat Nov 17 18:33:51 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Sat, 17 Nov 2007 19:33:51 +0100 Subject: [postmodern-devel] Warnings from bordeaux-threads In-Reply-To: <017f01c82945$2f222bf0$6502a8c0@JensSony> References: <017f01c82945$2f222bf0$6502a8c0@JensSony> Message-ID: Hello Jens, Did you re-compile completely after disabling threads? (Remove all .fasl files -- this is a compile-time option.) Note that this will mean that connection pools are no longer thread-safe, which might be a problem in some applications. The problem you are seeing does seem to be related to bordeaux-threads... but you could check this by making a small dummy project which uses bordeaux-threads but not postmodern, and seeing if you can build a stand-alone app from that. Cheers, Marijn From info at jensteich.de Sat Nov 17 18:45:15 2007 From: info at jensteich.de (Jens Teich) Date: Sat, 17 Nov 2007 19:45:15 +0100 Subject: [postmodern-devel] Warnings from bordeaux-threads References: <017f01c82945$2f222bf0$6502a8c0@JensSony> Message-ID: <019501c82949$ffe5a290$6502a8c0@JensSony> Marijn Haverbeke wrote: > Hello Jens, > > Did you re-compile completely after disabling threads? (Remove all > .fasl files -- this is a compile-time option.) This sounds like beeing my problem. > Note that this will > mean that connection pools are no longer thread-safe, which might be a > problem in some applications. The problem you are seeing does seem to > be related to bordeaux-threads... but you could check this by making a > small dummy project which uses bordeaux-threads but not postmodern, > and seeing if you can build a stand-alone app from that. I'm not sure and will be cautious. I'm looking to solve the underying problem in bordeaux-threads first. Thanks for the quick response. Jens From marijnh at gmail.com Mon Nov 19 15:51:29 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Mon, 19 Nov 2007 16:51:29 +0100 Subject: [postmodern-devel] development plans for discussion In-Reply-To: References: Message-ID: > i'll try to make iolib compile-time pluggable and if it's not too > kludgy then i'll record it and report back. I was thinking about this today -- maybe it would be easiest to implement a USocket backend based on IOLib, with dynamic variables to configure things that the USocket interface does not incorporate (such as timeouts). That way, Postmodern would not have to be changed, and the same code could be used in other projects that use USocket. You could even ask Eric if he'd be interested in incorporating such things in the general USocket interface. Marijn