Re: RangeVarGetRelid()

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Noah Misch <noah@leadboat.com>

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

Date: 2011-12-20T04:52:54Z

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

Attachments

rangevargetrelid-callback-round3.patch (application/octet-stream) patch

On Mon, Dec 19, 2011 at 3:12 PM, Noah Misch <noah@leadboat.com> wrote:
> I'm satisfied that you and I have a common understanding of the options and
> their respective merits.  There's plenty of room for judgement in choosing
> which merits to seize at the expense of others.  Your judgements here seem
> entirely reasonable.

Thanks.  I'm not trying to be difficult.

After staring at this for quite a while longer, it seemed to me that
the logic for renaming a relation was similar enough to the logic for
changing a schema that the two calbacks could reasonably be combined
using a bit of conditional logic; and that, further, the same callback
could be used, with a small amount of additional modification, for
ALTER TABLE.  Here's a patch to do that.

I also notice that cluster() - which doesn't have a callback - has
exactly the same needs as ReindexRelation() - which does.  So that
case can certainly share code; though I'm not quite sure what to call
the shared callback, or which file to put it in.
RangeVarCallbackForStorageRewrite?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company