From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: RangeVarGetRelid() |
Date: | 2011-11-18 13:58:30 |
Message-ID: | CA+TgmoZbj3n0+GeutBh0WzvcJTwA3rvjmXki-Ad++t+oejjN6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Nov 18, 2011 at 8:37 AM, Noah Misch <noah(at)leadboat(dot)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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-18 14:11:27 | Re: Inlining comparators as a performance optimisation |
Previous Message | Thom Brown | 2011-11-18 13:51:16 | Re: VACUUM touching file but not updating relation |