KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
> However, I think we have a few issues, and it makes unclear whether
> we can make an agreement in the community.
> The one is a cost of security hooks. They consume a bit more CPU steps
> when a security mechanism is enabled. The other is prevention to override
> a few hooks (ExecutorRun_hook and planner_hook), because they assume
> standard implementations to be executed.
I think your chances of taking those hooks away are zero. It would
cripple a lot of other facilities that people are more interested in
than they are in SEPostgres. In any case, the only way to use those
hooks is to load C code into the backend, and anyone who can do that
already has the keys to the kingdom. I hope you are not suffering
from any illusions about being able to defend against arbitrary add-on
C code.
regards, tom lane