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 |
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 |