Re: Command Triggers - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Command Triggers
Date
Msg-id 201201182151.49439.andres@anarazel.de
Whole thread Raw
In response to Re: Command Triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wednesday, January 18, 2012 08:31:49 PM Tom Lane wrote:
> Dimitri Fontaine <dimitri@2ndQuadrant.fr> writes:
> > We can easily enough copy the parse tree and do another round of parse
> > analysis on it only when some command triggers are going to get called.
> > Is the cost of doing so acceptable?
> 
> It's not the costs I'm worried about so much as the side effects ---
> locks and so forth.  Also, things like assignment of specific names
> for indexes and sequences seem rather problematic.  In the worst case
> the trigger could run seeing "foo_bar_idx1" as the name of an index
> to be created, and then when the action actually happens, the name
> turns out to be "foo_bar_idx2" because someone else took the first name
> meanwhile.
You can't generally assume such a thing anyway. Remember there can be BEFORE 
command triggers. It would be easy to create a conflict there.

The CREATE TABLE will trigger command triggers on CREATE SEQUENCE and ALTER 
SEQUENCE while creating the table. If one actually wants to do anything about 
those that would be the place.

> As I said, I think this suggests that you're trying to do the triggers
> in the wrong place.
In my opinion it mostly shows that parse analysis of utlity statments is to 
intermingled with other stuff.... Not sure what to do about that.


Andres


pgsql-hackers by date:

Previous
From: Jignesh Shah
Date:
Subject: Re: [WIP] Double-write with Fast Checksums
Next
From: Martin Pihlak
Date:
Subject: Re: Patch review for logging hooks (CF 2012-01)