Re: Extend argument of OAT_POST_CREATE
От | Alvaro Herrera |
---|---|
Тема | Re: Extend argument of OAT_POST_CREATE |
Дата | |
Msg-id | 20121010161307.GC9594@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Extend argument of OAT_POST_CREATE (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: Extend argument of OAT_POST_CREATE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: