Thought about that. But if you have a user run through your system
and locks all the tables for a long time the least of my worries are
the permissions. Generally it's getting that damn user disconnected
then taken out back shot so that the system is moving forward again.
Anyway, the point was that if Postgresql is going to be worried about
users running stored plans on functions they don't have permission on,
then a user shouldn't expect permission to be revoked in the middle of
a transaction if they hold a lock on the item.
--
Rod Taylor
This message represents the official view of the voices in my head
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Rod Taylor" <rbt@zort.ca>
Cc: "Peter Eisentraut" <peter_e@gmx.net>; "PostgreSQL Development"
<pgsql-hackers@postgresql.org>
Sent: Wednesday, February 13, 2002 5:29 PM
Subject: Re: [HACKERS] When and where to check for function
permissions
> "Rod Taylor" <rbt@zort.ca> writes:
> > I'd expect the revoke statement to be blocked by
> > the locks on those rows.
>
> We could do it that way, but it doesn't seem like a really good idea
to
> me --- in essence you'd be allowing a denial-of-service attack, no?
>
> regards, tom lane
>
