Robert Haas <robertmhaas@gmail.com> writes:
> I don't want to go there, and it's not what Tom was proposing anyway.
> The idea is - if the user creates a function which is NOT a trusted
> procedure and executes it, and then subsequently changes the system
> security policy so that it becomes a trusted procedure, the user will
> be responsible for flushing the cached plans before the new value will
> take effect.
Yeah. Given the rather limited set of things that can be inlined,
I don't think that it's worth the complexity or performance cost to
do differently. Note also that it's pretty easy to force the cache
flush if you are the procedure's owner: any sort of dummy ALTER on
the procedure should do it.
Mind you, I think there probably *is* a case for fixing REVOKE to force
a cache flush on the procedure as well. I just don't want to have to
deal with magic outside-the-database changes.
regards, tom lane