[HACKERS] Placement of InvokeObjectPostAlterHook calls
От | Tom Lane |
---|---|
Тема | [HACKERS] Placement of InvokeObjectPostAlterHook calls |
Дата | |
Msg-id | 11419.1483725181@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Placement of InvokeObjectPostAlterHook calls
|
Список | pgsql-hackers |
While reviewing Etsuro-san's patch to force replanning after FDW option changes, I noticed that there is a great lack of consistency about where InvokeObjectPostAlterHook calls have been placed relative to other actions such as forced relcache invals. I wonder exactly what expectations a post-alter hook function could have about cache coherency, or indeed if there's any clarity at all about what such a hook might do. For instance, it looks to me like the hook would generally need to do a CommandCounterIncrement in order to be able to "see" the update it's being called for, and I'm unsure that that would be safe at every call site. Is that supposed to be allowed, or are we expecting that object access hooks are only going to do open-loop actions that don't rely on the details of the change? I suppose this fits in well with our grand tradition of not documenting hooks at all, but for a set of hooks as invasive as these are, I think we ought to do better. regards, tom lane
В списке pgsql-hackers по дате отправления: