(2010/10/07 6:21), Alvaro Herrera wrote:
Excerpts from Robert Haas's message of miƩ oct 06 17:02:22 -0400 2010:
2010/10/5 KaiGai Kohei<kai...@ak.jp.nec.com>:

However, we also have a few headache cases.
DefineType() creates a new type object and its array type, but it does not
call CommandCounterIncrement() by the end of this function, so the new type
entries are not visible from the plugin modules, even if we put a security
hook at tail of the DefineType().
DefineFunction() also has same matter. It create a new procedure object,
but it also does not call CommandCounterIncrement() by the end of this
function, except for the case when ProcedureCreate() invokes language
validator function.

So I guess the first question here is why it's important to be able to
see the new entry.  I am thinking that you want it so that, for
example, you can fetch the namespace OID to perform an SE-Linux type
transition.  Is that right?

I'm not sure that there's any point trying to optimize these to the
point of avoiding CommandCounterIncrement.  Surely DefineType et al are
not performance-sensitive operations.

Performance optimization is not the point here.

If we need to call CommandCounterIncrement() before invocation of security
hooks, we also need to analyze its side-effect and to confirm it is harmless.
Even if it is harmless, I think it gives us more burden of code maintenance
than the idea of two hooks on creation.

Maybe we need a variant of InvokeObjectAccessHook that does a CCI only
if a hook is present.

The problem I see with this idea is that it becomes a lot harder to
track down whether it ocurred or not for any given operation.

Yes, it is a burden of code maintenance.

Thanks,
--
KaiGai Kohei <kai...@ak.jp.nec.com>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to