??>> and taking into account other cursor operations, instead of 3 query ??>> templates we now have something like 12 different queries now, and ??>> i see any pattern how they can be merged :( ??>> or maybe it makes sense to ditch templated query generations and just ??>> write these conditions manually
LPP> I took a look at it. CURSOR-FETCH-QUERY is complicated enough as it LPP> is, so let's reduce it to some common primitives as far as possible LPP> and implement our NULL cases manually. it seems only it's where-generating part needs to be replaced (as well as parameters value-compare and key-compare), or you have some other restructuring in mind? here's the whole table btw: cursor-next (duplicates allowed) key is null: (qi IS NULL) and (value > $2) key is not null: (qi > $1) OR (qi IS NULL) OR ((qi = $1) AND (value > $2) cursor-prev (duplicates allowed) key is null: (qi IS NOT NULL) OR ((qi IS NULL) AND (value < $2)) key is not null: (qi < $1) OR ((qi = $1) AND (value < $2)) cursor-next-nodup: key is null: do nothing key is not null: (qi > $1) OR (qi is NULL) cursor-prev-nodup: key is null: (qi IS NOT NULL) key is not null: (qi < $1) cursor-set-range: key is null: (qi IS NULL) key is not null: (qi >= $1) OR (qi IS NULL) cursor-get-both-range: key is null: (qi IS NULL) AND (value >= $2) key is not null: (qi = $1) AND (value >= $2) i don't see some clear patter here, so we can just explicitly pass where part to cursor-fetch-query function. also i have some concerns that postgres might fail to optimize bigger conditionals in where.. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
