Re: RangeVarGetRelid() - Mailing list pgsql-hackers

From Noah Misch
Subject Re: RangeVarGetRelid()
Date
Msg-id 20111216153239.GA2861@tornado.leadboat.com
Whole thread Raw
In response to Re: RangeVarGetRelid()  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RangeVarGetRelid()
List pgsql-hackers
On Thu, Dec 15, 2011 at 07:04:20PM -0500, Robert Haas wrote:
> On Fri, Dec 9, 2011 at 5:41 PM, Noah Misch <noah@leadboat.com> wrote:
> > It also seems my last explanation didn't convey the point. ?Yes, nearly every
> > command has a different set of permissions checks. ?However, we don't benefit
> > equally from performing each of those checks before acquiring a lock.
> > Consider renameatt(), which checks three things: you must own the relation,
> > the relation must be of a supported relkind, and the relation must not be a
> > typed table. ?To limit opportunities for denial of service, let's definitely
> > perform the ownership check before taking a lock. ?The other two checks can
> > wait until we hold that lock. ?The benefit of checking them early is to avoid
> > making a careless relation owner wait for a lock before discovering the
> > invalidity of his command. ?That's nice as far as it goes, but let's not
> > proliferate callbacks for such a third-order benefit.
>
> I agree, but my point is that so far we have no callbacks that differ
> only in that detail.  I accept that we'd probably want to avoid that.

To illustrate what I had in mind, here's a version of your patch that has five
callers sharing a callback.  The patch is against d039fd51f79e, just prior to
your recent commits.

Attachment

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: archive_keepalive_command
Next
From: Greg Smith
Date:
Subject: Re: [PATCH] Caching for stable expressions with constant arguments v3