[elephant-devel] Ditching Darcs
Alex Mizrahi
killerstorm at newmail.ru
Tue Oct 28 20:02:29 UTC 2008
??>> 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..
More information about the elephant-devel
mailing list