On Mon, 31 Jul 2006, Kamesh Jayachandran wrote:
> Daniel Rall wrote:
> >On Fri, 28 Jul 2006, Kamesh Jayachandran wrote:
> >
> >
> >>Daniel Rall wrote:
> >>
> >>>Okay -- we need to always do the cleanup, 'cuz if we don't we could
> >>>leave stray records around the merge info index. Which don't actively
> >>>harm anything, but perhaps should be deleted...
> >>>
> >>>The API probably shouldn't be named index_merge_info(), then.
> >>>update_merge_info() would be better, but is already taken. Should we
> >>>merge the two routines into a single routine, or rename the existing
> >>>update_merge_info() function to something more specific?
> >>>
> >>>
> >>>
> >>Find the attached patch.
> >>
> >
> >I've committed a variation of this in r20923 which uses slightly less
> >SQL-y function names.
> >
> >I take it you didn't like the idea of merging the merge info index
> >entry point function you added and the function which loops over any
> >merge info for a transaction?
>
> I overlooked at it, will see it through.
While conceptually it's fine, I'm worried that it might hurt
comprehensibility, since it'll make a rather large single function out
of two separate functions which are nicely modularized (though have
only one caller each).
- application/pgp-signature attachment: stored
Received on Tue Aug 1 18:42:55 2006