Re: Lock conflict behavior? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Lock conflict behavior?
Date
Msg-id 1232579332.3578.91.camel@dell.linuxdev.us.dell.com
Whole thread Raw
In response to Re: Lock conflict behavior?  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Lock conflict behavior?  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Wed, 2009-01-21 at 17:39 -0500, Bruce Momjian wrote:
> > It looks like it would be easy enough to throw a better error message
> > than that, e.g. with a try/catch. The information could be obsolete, but
> > if it succeeds, it would at least mean they had permissions at some time
> > in the past.
> > 
> > Or, we could just remove the ACL checks from LOCK TABLE, so that it's at
> > least consistent. Mostly it's the inconsistency that bothers me.
> 
> Is this a TODO?

I don't feel too strongly about it. I would feel better if we were
consistent about the permissions checks, because there's less of a
chance for confusion or a false sense of security.

If we keep the permission check in LockTableCommand(), I can make a
patch that produces a more useful error message when the table is
removed right before the pg_class_aclcheck().

Right now it does:
ERROR:  relation with OID 16542 does not exist

which is undesirable.

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Pluggable Indexes (was Re: rmgr hooks (v2))
Next
From: Josh Berkus
Date:
Subject: Re: Pluggable Indexes (was Re: rmgr hooks (v2))