[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