Robert Haas <robertmhaas@gmail.com> writes:
> As I said, I wasn't sure we wanted to commit to the API enough to
> document it, and by the time you get done whacking the stuff above
> around, the documentation KaiGai wrote for it (which was also badly in
> need of editing by a native English speaker) would have been mostly
> obsolete anyway. But I'm willing to put some effort into it once you
> get done rearranging the furniture, if that's helpful.
I thought of another API change we should consider. It's weird that
CustomPathMethods includes CreateCustomScanPath, because that's not
a method you apply to a CustomPath, it's what creates them in the first
place. I'm inclined to think that we should get rid of that and
register_custom_path_provider() altogether and just provide a function
hook variable equivalent to create_customscan_paths, which providers can
link into in the usual way. The register_custom_path_provider mechanism
might have some use if we were also going to provide deregister-by-name
functionality, but as you pointed out upthread, that's not likely to ever
be worth doing.
The hook function might better be named something like
editorialize_on_relation_paths, since in principle it could screw around
with the Paths already made by the core code, not just add CustomPaths.
There's an analogy to get_relation_info_hook, which is meant to let
plugins editorialize on the relation's index list. So maybe
set_plain_rel_pathlist_hook?
regards, tom lane
