Excuse me for cutting in, 2012/4/6 Shigeru HANADA <shigeru.han...@gmail.com>: > To support foreign-table ANALYZE by adding a new hook, we would need a > mechanism (or at least documented guide lines) to manage the chain of > hook functions, because such hook might be used by multiple FDWs (or > other plug-ins) at the same time. A wrongly-written plug-in can easily > break the hook chain. We might need to provide register/unregister API > for this hook point, like RegisterResourceReleaseCallback, and call each > registered function until either of them processes the request. Is > there any other hook point which has similar issue?
+1 Plain hook mechanism in PostgreSQL is, I think, to hang a bunch of faceless callbacks to be registered, unregistered and called all together. And it does not fit to manage individual callbacks which may be registered or unregistered in arbitrary order and are preferred to be called separately. Although we provide RegisterResourceReleaseCallback-like staff, it seems far more complicated than the additional field in FdwRoutine and some analyze_rel() modifications in core-side, and confirmation of whether it's really the time for me should be a reluctant work in plugin-side. Of cource, I don't think there will be so many fdw-analyze callbacks registered but two seems sufficient. The current mods in analyze_rel() does not look definitive, but it does not look so bad and seems more stable than simple hook point which will be abandoned before long. > Another concern is the place where we hook the process of ANALYZE. IOW, > how much portion of ANALYZE should be overridable? Replacing > analyze_rel or do_analyze_rel wholly requires plug-ins to copy most of > codes from original function in order to implement hook function. From > the perspective of FDW author, I think that row sampling > (acquire_sample_rows) function seems handy place to hook. regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers