Re: RangeVarGetRelid()

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Alvaro Herrera <alvherre@commandprompt.com>, Pg Hackers <pgsql-hackers@postgresql.org>

Date: 2011-11-18T14:12:38Z

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 →

Try to acquire relation locks in RangeVarGetRelid.
- 4240e429d0c2 9.2.0 cited

On Fri, Nov 18, 2011 at 08:58:30AM -0500, Robert Haas wrote:
> On Fri, Nov 18, 2011 at 8:37 AM, Noah Misch <noah@leadboat.com> wrote:
> > I count 1/25 callers overriding nowait and 3/25 overriding missing_ok. ?So, it's
> > looking like a less-common override than the callback function will come to be.
> 
> Yeah, you're probably right.  However, I think there's another good
> reason not to use that signature: in 9.1, the function had a signature
> of (RangeVar *, bool).  If in 9.2 it ends up with a signature of
> (RangeVar *, LOCKMODE), you won't get a compiler warning (at least not
> on my system) if you invoke it as RangeVarGetRelid(rel, true).  You'll
> just get silently (and subtly) different behavior: an error if the
> relataion doesn't exist (instead of no error), and an AccessShareLock
> if it does (instead of no lock).  I think we're best off making sure
> that any old-style usage of RangeVarGetRelid() that may be out there
> in third-party code fails to compile.

Good call.