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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
