Re: Event Triggers: adding information

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Event Triggers: adding information
Date: 2012-12-29 13:11:00
Message-ID: CA+TgmoZTxXGAkoyQD0aNOyju1X19SnVfk7KV9fsJCv63bS-C4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Dec 25, 2012 at 1:42 PM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> Also, keep in mind we want the ObjectID in all CREATE, ALTER and DROP
>>> statements, so my current patch is still some bricks shy of a load… (I
>>> added ObjectID only in the commands I added rewrite support for, apart
>>> from DROP).
>>
>> I shall rely on you to provide those bricks which are still missing.
>
> Please find attached a patch to change most functions called from
> standard_ProcessUtility() to return an Oid (passes `make
> maintainer-clean; configure; make install check`). Most of them only,
> because it only make sense for functions touching an object that exists
> in the catalogs and have a distinct Oid.

OK, I committed this.

> That completes ALTER and CREATE ObjectID support, I did nothing about
> the DROP case in the attached. The way I intend to solve that problem is
> using get_object_address() and do an extra lookup from within the Event
> Trigger code path.

An extra lookup that occurs always, or only when event triggers are in
use? A re-resolution of the name, or some other kind of lookup?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dimitri Fontaine 2012-12-29 13:41:48 Re: Event Triggers: adding information
Previous Message Daniel Farina 2012-12-29 13:02:46 Re: pg_stat_statements: calls under-estimation propagation