Re: sepgsql contrib module

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