Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement()
Date
Msg-id CA+Tgmob0jOz-JP0uXDnY+eDQ7pFn2pOjoET1UxF10_WEJEh7DQ@mail.gmail.com
Whole thread Raw
In response to Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement()  (Ants Aasma <ants.aasma@eesti.ee>)
Responses Re: InvokeObjectPostAlterHook() vs. CommandCounterIncrement()  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
On Sun, Jul 21, 2013 at 4:44 AM, Ants Aasma <ants.aasma@eesti.ee> wrote:
> On Jul 21, 2013 4:06 AM, "Noah Misch" <noah@leadboat.com> wrote:
>> If these hooks will need to apply to a larger operation, I
>> think that mandates a different means to reliably expose the before/after
>> object states.
>
> I haven't checked the code to see how it would fit the API, but what about
> taking a snapshot before altering and passing this to the hook. Would there
> be other issues besides performance? If the snapshot is taken only when
> there is a hook present then the performance can be fixed later.

I had the idea of finding a way to pass either the old tuple, or
perhaps just the TID of the old tuple.  Not sure if passing a snapshot
is better.

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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.
Next
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Add support for REFRESH MATERIALIZED VIEW CONCURRENTLY.