Re: RangeVarGetRelid() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: RangeVarGetRelid()
Date
Msg-id CA+TgmoZUmuYkLp6LdhN1vTFdq37xj4cOf0ttjqcaDqnxqJBhbg@mail.gmail.com
Whole thread Raw
In response to Re: RangeVarGetRelid()  (Noah Misch <noah@leadboat.com>)
Responses Re: RangeVarGetRelid()  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Nikhil Sontakke
Date:
Subject: Re: Review: Non-inheritable check constraints
Next
From: Robert Haas
Date:
Subject: Re: JSON for PG 9.2