Horton

Re: sepgsql contrib module

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, KaiGai Kohei <kaigai@ak.jp.nec.com>, PgHacker <pgsql-hackers@postgresql.org>
Date: 2011-01-21T16:45:55Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pgindent run for 9.0, second run

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