Re: RangeVarGetRelid()

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-12-20 04:52:54
Message-ID: CA+TgmoZUmuYkLp6LdhN1vTFdq37xj4cOf0ttjqcaDqnxqJBhbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 19, 2011 at 3:12 PM, Noah Misch <noah(at)leadboat(dot)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

Attachment Content-Type Size
rangevargetrelid-callback-round3.patch application/octet-stream 18.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-12-20 05:00:37 Re: JSON for PG 9.2
Previous Message Nikhil Sontakke 2011-12-20 04:38:58 Re: Review: Non-inheritable check constraints