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