Simon Riggs <simon@2ndQuadrant.com> writes:
> On Fri, 2009-01-23 at 10:33 -0500, Tom Lane wrote:
>> Right, the WAL-record-processing API is not really at issue, since it's
>> been proven internally to the core code. My concern is with the other
>> part, namely exactly how are we going to identify and install additional
>> rmgrs.
> The patch is just
> * a hook in StartupXLOG to allow loading arbitrary code into Startup
> * some slight redefinition of RmgrTable to allow arbitrary code to add
> or modify the contents of that table of functions. (Being able to modify
> the table is an not necessary for index extensions, but is for other
> uses).
> * some safeguards people requested
Well, that really seems to just prove my point. You've defined a hook
and not thought carefully about how people will use it. The main thing
that I can see right now that we'd need is some way to determine who
gets which rmgr index. (Maybe community assignment of numbers ---
similar to what we've defined for pg_statistic kind codes --- is fine,
or maybe it isn't; in any case we need an answer for that before this
hook can be considered usable.) Furthermore, maybe that's not the only
problem. I'd feel a lot better about this if the hook patch were done
in parallel with development of actual WAL support in an actual external
indexam. As was suggested earlier, we could do something like building
hash as an external module for the sake of this development, so it's not
like I'm demanding someone write a whole AM from scratch for this. But
putting in the hook and leaving people to invent their own ways of using
it is a recipe for conflicts.
regards, tom lane
