Kohei KaiGai escribió:
> The attached patch adds argument of OAT_POST_CREATE hook;
> to inform extensions type of the context of this object creation. It allows
> extensions to know whether the new object is indirectly created apart
> from user's operations, or not.
Can we add Assert(!is_internal) to the ProcedureRelationId case in
sepgsql_object_access() too? I don't see any caller that would set it
true anywhere, but maybe you have a good reason for omitting it.
I'm not clear on what's sepgsql_relation_setattr for; it doesn't seem to
be called anywhere (other than sepgsql_relation_setattr_extra, but
that's static, so why isn't sepgsql_relation_setattr also static?). But
I notice that it calls sepgsql_index_modify without first checking for
the toast namespace like the other callers do. Is this okay or an
oversight?
I admit the new RELKIND_INDEX cases in various places make for strange
flow. Not sure how it can be improved though.
I didn't find anything wrong with the changes to src/backend. One thing
that I noticed is that when bootstrapping, all relation creation is
considered internal. I am sure this is okay fo the normal case, but I
wonder if a malicious superuser could get a hold of things that he
shouldn't by starting a bootstrapping backend and run relation creation
there.
Note: I can compile sepgsql but not run the regression tests.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
