Forum OpenACS Development: Response to New implementation of tree_sortkey

Collapse
Posted by Don Baccus on
David, yes, building the list of identifiers in Tcl would work, but it can also be done in PL/pgSQL thus hiding it from the Tcl code (as we're trying to do with all DB-dependent code).  That was one of my ideas for finding parents faster.  I tried the recursive SQL function trick and ran into the roadblock that PG 7.1 doesn't support such recursiveness.  Drat!  I was bummed out.  It's welcome news to learn that PG 7.2 has removed the restriction, I wasn't aware of that.

As far as the triggers go ... for starters, your own custom tables could  continue to use the "text" type triggers, there's no need for every table to do it the same way.  Though overall it's cleaner, of course.  The triggers do need changing but the changes are very minor.  Probably the best thing to do is to look at some examples after I commit my changes this weekend and decide if the benefits are worth your changing this stuff for *your* tables.

Breaking the coupling with the collation sequence is the most important benefit of doing it the new way, IMO.

Jun ... no guarantees on the Dec 3rd CVS tree.  I was making some changes to the use of the old style sortkeys (using BETWEEN rather than LIKE in order to pick up the index on tree_sortkey) and was doing some testing before updating.  But ... that's transition code.  We're not making promises that every night's CVS tree will work.  Overall, the nightly tarballs have been in good shape for all but a handfull of nights but I'd consider that "luck".