From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: invalidating cached plans |
Date: | 2005-03-16 05:11:58 |
Message-ID: | 2484.1110949918@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark <gsstark(at)mit(dot)edu> writes:
> That makes me wonder. What happens if I prepare a query, then use SET SESSION
> AUTHORIZATION to change my user. Then try to execute the query?
Permissions checks are applied at executor startup, not by the planner,
so it should Work Correctly in my view of the world.
There is one exception: a potentially inlinable SQL function will be
inlined if it is allowably executable when the planner wants to do it
--- subsequent revocation of call privileges on the function won't
cause a failure of the plan. You could argue it both ways about
whether this is a problem, but it seems to me it's not a big issue.
We don't inline functions that could, say, give you access to a table
you couldn't have read otherwise.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Kirkwood | 2005-03-16 05:23:07 | Re: contrib/pg_buffercache |
Previous Message | Rod Taylor | 2005-03-16 03:57:49 | Real-Time Vacuum Possibility |